info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Automatically doing something if logged in
7 views
Skip to first unread message
bit-n...@hotmail.com
Feb 22, 2016, 1:02:49 PM2/22/16
to
Hi,
So say there's a forum site, and if there' been a reply to a post I've made, it sends me a link to that thread. If I click on it, and I've remained logged in when I was there last, then it *automatically takes me to that thread*. If I wasn't, then it shows me a Login box - when I log in it *automatically takes me to that thread*, but if I just went to the homepage NOT clicking on any email link, and I THEN log in, then it shows me something else (like "My homepage" or something), NOT that thread.
It's quite late, am I making sense? :)
How is this pulled off?
Like, the "login.html" page checks to see if the cookie is set? If it is, it takes me to that page directly? And if not, then it shows the "login box" with a ?threadid=something and then if the authentication is successful, then the login script checks to see if there's a "threadid" argument, and if so, redirects me to that page? This is how it *seems* to me intuitively, that it Should be coded, but how do I actually code it? :) Is there anything I'm missing?
Thanks for your help.
So say there's a forum site, and if there' been a reply to a post I've made, it sends me a link to that thread. If I click on it, and I've remained logged in when I was there last, then it *automatically takes me to that thread*. If I wasn't, then it shows me a Login box - when I log in it *automatically takes me to that thread*, but if I just went to the homepage NOT clicking on any email link, and I THEN log in, then it shows me something else (like "My homepage" or something), NOT that thread.
It's quite late, am I making sense? :)
How is this pulled off?
Like, the "login.html" page checks to see if the cookie is set? If it is, it takes me to that page directly? And if not, then it shows the "login box" with a ?threadid=something and then if the authentication is successful, then the login script checks to see if there's a "threadid" argument, and if so, redirects me to that page? This is how it *seems* to me intuitively, that it Should be coded, but how do I actually code it? :) Is there anything I'm missing?
Thanks for your help.
Jerry Stuckle
Feb 22, 2016, 2:04:37 PM2/22/16
to
check to see if they are logged in or not. If not, then it needs to
redirect to the login page. Before the redirect, it could save the
eventual target several ways - it could be a parameter in the redirect,
for instance. But more often it's a session or cookie value. (In this
case a cookie value would not be a security risk because the link is
public, anyway).
Then, on a successful login, it gets the cookie or session value and
redirects to that page.
There are multiple ways to do this, but this is the basic flow.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================
J.O. Aho
Feb 22, 2016, 2:21:57 PM2/22/16
to
On 02/22/2016 07:02 PM, bit-n...@hotmail.com wrote:
> Hi,
> So say there's a forum site, and if there' been a reply to a post I've made, it sends me a link to that thread. If I click on it, and I've remained logged in when I was there last, then it *automatically takes me to that thread*. If I wasn't, then it shows me a Login box - when I log in it *automatically takes me to that thread*, but if I just went to the homepage NOT clicking on any email link, and I THEN log in, then it shows me something else (like "My homepage" or something), NOT that thread.
> It's quite late, am I making sense? :)
> How is this pulled off?
If you want things to happen "automagically", then you need to think
> Hi,
> So say there's a forum site, and if there' been a reply to a post I've made, it sends me a link to that thread. If I click on it, and I've remained logged in when I was there last, then it *automatically takes me to that thread*. If I wasn't, then it shows me a Login box - when I log in it *automatically takes me to that thread*, but if I just went to the homepage NOT clicking on any email link, and I THEN log in, then it shows me something else (like "My homepage" or something), NOT that thread.
> It's quite late, am I making sense? :)
> How is this pulled off?
more than just PHP, add some javascript (there are loads of good
frameworks) and use websockets.
--
//Aho
Jerry Stuckle
Feb 22, 2016, 2:52:56 PM2/22/16
to
appropriate tests and redirects. No javascript, websockets or anything
else is required.
Thomas 'PointedEars' Lahn
Feb 22, 2016, 4:25:57 PM2/22/16
to
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.
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/>
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.
J.O. Aho
Feb 23, 2016, 12:58:14 AM2/23/16
to
On 02/22/2016 08:52 PM, Jerry Stuckle wrote:
> On 2/22/2016 2:21 PM, J.O. Aho wrote:
>> On 02/22/2016 07:02 PM, bit-n...@hotmail.com wrote:
>>> Hi,
>>> So say there's a forum site, and if there' been a reply to a post I've made, it sends me a link to that thread. If I click on it, and I've remained logged in when I was there last, then it *automatically takes me to that thread*. If I wasn't, then it shows me a Login box - when I log in it *automatically takes me to that thread*, but if I just went to the homepage NOT clicking on any email link, and I THEN log in, then it shows me something else (like "My homepage" or something), NOT that thread.
>>> It's quite late, am I making sense? :)
>>> How is this pulled off?
>>
>> If you want things to happen "automagically", then you need to think
>> more than just PHP, add some javascript (there are loads of good
>> frameworks) and use websockets.
>>
>>
>
> Actually, it can be done without a lot of trouble in PHP with the
> appropriate tests and redirects. No javascript, websockets or anything
> else is required.
>
You are right. I was thinking a step further, where someone replied when
> On 2/22/2016 2:21 PM, J.O. Aho wrote:
>> On 02/22/2016 07:02 PM, bit-n...@hotmail.com wrote:
>>> Hi,
>>> So say there's a forum site, and if there' been a reply to a post I've made, it sends me a link to that thread. If I click on it, and I've remained logged in when I was there last, then it *automatically takes me to that thread*. If I wasn't, then it shows me a Login box - when I log in it *automatically takes me to that thread*, but if I just went to the homepage NOT clicking on any email link, and I THEN log in, then it shows me something else (like "My homepage" or something), NOT that thread.
>>> It's quite late, am I making sense? :)
>>> How is this pulled off?
>>
>> If you want things to happen "automagically", then you need to think
>> more than just PHP, add some javascript (there are loads of good
>> frameworks) and use websockets.
>>
>>
>
> Actually, it can be done without a lot of trouble in PHP with the
> appropriate tests and redirects. No javascript, websockets or anything
> else is required.
>
you was already logged in and was already at page X and needed a
redirect to page Y without the request of an user action.
--
//Aho
J.O. Aho
Feb 23, 2016, 1:04:47 AM2/23/16
to
On 02/22/2016 10:25 PM, Thomas 'PointedEars' Lahn wrote:
life), those who still use those old version deserve to get malware.
Current supported firefox versions are Firefox 38.6.1 ESR and Firefox
44.0.2.
--
//Aho
> J.O. Aho wrote:
> 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]),
Who cares about version 4 to 23, those ain't supported any more (end of
> 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]),
life), those who still use those old version deserve to get malware.
Current supported firefox versions are Firefox 38.6.1 ESR and Firefox
44.0.2.
--
//Aho
Arno Welzel
Feb 23, 2016, 2:10:12 AM2/23/16
to
as a parameter to the login page or set a cookie which will be used by
the login page to redirect to the target after successful login etc..
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de
Arno Welzel
Feb 23, 2016, 2:24:17 AM2/23/16
to
Thomas 'PointedEars' Lahn schrieb am 2016-02-22 um 22:25:
[...]
WebSocket example at <https://arnowelzel.de/tools/chat/>, all major
browsers (Firefox, Chrome, Internet Explorer and even most mobile
browsers) support it.
Also see <http://caniuse.com/#feat=websockets>
> 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.
ACK. XHR is easier to implement.
[...]
> 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
Yes, it is experimental. But at least since May 2014, when I created my
> 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
WebSocket example at <https://arnowelzel.de/tools/chat/>, all major
browsers (Firefox, Chrome, Internet Explorer and even most mobile
browsers) support it.
Also see <http://caniuse.com/#feat=websockets>
> 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.
Thomas 'PointedEars' Lahn
Feb 23, 2016, 2:31:55 AM2/23/16
to
J.O. Aho wrote:
> On 02/22/2016 10:25 PM, Thomas 'PointedEars' Lahn wrote:
>> 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]),
>
> Who cares about version 4 to 23, those ain't supported any more (end of
> life), those who still use those old version deserve to get malware.
A Web application that does not work because an unwise design decision has
> On 02/22/2016 10:25 PM, Thomas 'PointedEars' Lahn wrote:
>> 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]),
>
> Who cares about version 4 to 23, those ain't supported any more (end of
> life), those who still use those old version deserve to get malware.
been made is not malware.
> Current supported firefox versions are Firefox 38.6.1 ESR and Firefox
> 44.0.2.
versions, and unnecessary to leverage in the OP’s use-case as it has been
misunderstood by you.
I also can see that, despite my friendly advice, you are continuing to
disregard the AUP of your provider in a blatantly anti-social way. *PLONK*
Thomas 'PointedEars' Lahn
Feb 23, 2016, 2:46:35 AM2/23/16
to
Arno Welzel wrote:
> Thomas 'PointedEars' Lahn schrieb am 2016-02-22 um 22:25:
> [...]
>> 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
>
> Yes, it is experimental. But at least since May 2014, when I created my
> WebSocket example at <https://arnowelzel.de/tools/chat/>, all major
> browsers (Firefox, Chrome, Internet Explorer and even most mobile
> browsers) support it.
>
> Also see <http://caniuse.com/#feat=websockets>
So it is not supported in Opera Mini 8 with a global market share of 4.79 %.
> Thomas 'PointedEars' Lahn schrieb am 2016-02-22 um 22:25:
> [...]
>> 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
>
> Yes, it is experimental. But at least since May 2014, when I created my
> WebSocket example at <https://arnowelzel.de/tools/chat/>, all major
> browsers (Firefox, Chrome, Internet Explorer and even most mobile
> browsers) support it.
>
> Also see <http://caniuse.com/#feat=websockets>
Users of browsers that someone did not define as “major” are not important
enough?
Arno Welzel
Feb 23, 2016, 5:37:05 AM2/23/16
to
Thomas 'PointedEars' Lahn schrieb am 2016-02-23 um 08:46:
> Arno Welzel wrote:
>
>> Thomas 'PointedEars' Lahn schrieb am 2016-02-22 um 22:25:
>> [...]
>>> 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
>>
>> Yes, it is experimental. But at least since May 2014, when I created my
>> WebSocket example at <https://arnowelzel.de/tools/chat/>, all major
>> browsers (Firefox, Chrome, Internet Explorer and even most mobile
>> browsers) support it.
>>
>> Also see <http://caniuse.com/#feat=websockets>
>
> So it is not supported in Opera Mini 8 with a global market share of 4.79 %.
> Users of browsers that someone did not define as “major” are not important
> enough?
I wouldn't call a browser which is used by less then 5% of all users a
> Arno Welzel wrote:
>
>> Thomas 'PointedEars' Lahn schrieb am 2016-02-22 um 22:25:
>> [...]
>>> 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
>>
>> Yes, it is experimental. But at least since May 2014, when I created my
>> WebSocket example at <https://arnowelzel.de/tools/chat/>, all major
>> browsers (Firefox, Chrome, Internet Explorer and even most mobile
>> browsers) support it.
>>
>> Also see <http://caniuse.com/#feat=websockets>
>
> So it is not supported in Opera Mini 8 with a global market share of 4.79 %.
> Users of browsers that someone did not define as “major” are not important
> enough?
"major" browser.
But since WebSockets and not supported *everywhere* I already agreed to
you that I would use XHR instead if it is important that most people can
use the application.
Thomas 'PointedEars' Lahn
Feb 23, 2016, 3:03:07 PM2/23/16
to
Arno Welzel wrote:
> Thomas 'PointedEars' Lahn schrieb am 2016-02-23 um 08:46:
>> Arno Welzel wrote:
>>> Also see <http://caniuse.com/#feat=websockets>
>> So it is not supported in Opera Mini 8 with a global market share of 4.79
>> %. Users of browsers that someone did not define as “major” are not
>> important enough?
>
> I wouldn't call a browser which is used by less then 5% of all users a
> "major" browser.
Interesting. Note that the numbers are misleading because among mobile
> Thomas 'PointedEars' Lahn schrieb am 2016-02-23 um 08:46:
>> Arno Welzel wrote:
>>> Also see <http://caniuse.com/#feat=websockets>
>> So it is not supported in Opera Mini 8 with a global market share of 4.79
>> %. Users of browsers that someone did not define as “major” are not
>> important enough?
>
> I wouldn't call a browser which is used by less then 5% of all users a
> "major" browser.
devices, Opera currently has a market share of 10.91 % according to
StatCounter. That would probably include Opera Mini 8, whereas at Opera 34
is listed at caniuse.com as the current version to have a market share of
0.68 %. So there is reason to be more careful in one’s analysis and design
decisions.
> But since WebSockets and not supported *everywhere* I already agreed to
> you that I would use XHR instead if it is important that most people can
> use the application.
recommend *in general* to use XHR *instead*. Anyhow, ISTM we are off-topic
now.
0 new messages