J.O. Aho <
us...@example.net> wrote:
JFYI: Abuse of the
example.net domain (and sibling second-level domains, and
the “example” TLD) is disregarding the “Sender Address” section of the
Acceptable Use Policy of
news.individual.net and “may cause termination of
access privileges without further notice. Amounts paid will not be
refunded, neither partly nor in full.”
<
http://news.individual.net/rules.php>
(Individuals abusing the “.invalid” TLD instead, which is mistakenly
recommended by that Usenet provider for everyday use with Usenet postings
instead of only private testing, end up in my killfile automatically.)
<
http://www.interhack.net/pubs/munging-harmful/>
ISTM that you have misunderstood the OP to mean that the viewport is
automatically scrolled to the thread if they are logged in, have the forum
displayed, and there are updates in that thread. (Because I misunderstood
it in the same way at first.) But that is actually not what was being
asked.
Instead, the OP wondered how following the same link in the same e-mail can
have different outcomes depending on the login state, and how submitting a
login form can have a different outcome if it was triggered by a link in an
e-mail.
What probably happens here is that the URI of the link contains the
thread/follow-up ID, and a cookie in the browser tells the forum/bulletin
board application (phpBB?) about the login state of the user. If the user
was not logged in before, then a login form is displayed that contains
hidden fields (“<input type="hidden" name="…" value="…">”) that are
populated with the thread/follow-up ID. The server-side script receiving
the submitted form data then does the same as if the link URI had been used
(presumably by server-side redirection) if the login is successful. The
login form is not populated with the thread/follow-up ID if the link is not
used to navigate to the form, so “something else” is shown instead if the
login is successful.
However, FWIW, following my comment on the use-case that you probably
misunderstood from the OP:
There is no “javascript” [0], and there are lots of *bad* frameworks for
client-side ECMAScript-based scripting.
Fortunately, a framework/library would be overkill here.
> and use websockets.
This is not a use-case where real-time updates are important and WebSocket
would therefore be one of the preferred choices. It suffices, for example,
if the thread(s) is/are checked for relevant updates every 5 seconds.
Therefore, one should take into consideration that client-side support for
WebSocket is still experimental [1] (and had been disabled in Firefox by
default from version 4 to 23 inclusive [2]), and it might not be feasible
to use a framework for PHP like Ratchet [3] on that server or with that
forum application. So it is better to use XMLHttpRequest [4] for the time
being (XML does not have to be used in the HTTP messages, JSON is more
lightweight), and pull the server-side application for updates (GET) e.g.
every 5 seconds.
___________
[0] <
http://PointedEars.de/es-matrix>
[1] <
https://developer.mozilla.org/en-US/docs/Web/API/WebSocket>
[2] <
http://www.0xdeadbeef.com/weblog/2010/12/disabling-websockets-for-firefox-4/>
[3] <
http://socketo.me/>
[4] <
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest>
--
PointedEars
Zend Certified PHP Engineer
<
http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.