sharing sessions through links..
Locked
12
12
Re: sharing sessions through links..
 
|
On Tue, Oct 28, 2008 at 1:32 PM, Randal L. Schwartz
<[hidden email]> wrote: > No, you don't need two cookies --- you need only one cookie, as I demonstrated > my magazine article > (http://www.stonehenge.com/merlyn/WebTechniques/col61.html). You can't count > on a cookie going away as a means of timing out of session, since the browser > can do whatever it wants and client-side software can lie. This can be handled with cookies by creating a random, secure key on the server for the session, and hashing the cookie with it, then you can validate the cookie with the key and invalidate the key when the session expires. Depends of course, on what you want to do with it. Dave -- Dave Bauer [hidden email] http://www.solutiongrove.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
>>>>> "Dave" == Dave Bauer <[hidden email]> writes:
Dave> This can be handled with cookies by creating a random, secure key on Dave> the server for the session, and hashing the cookie with it, then you Dave> can validate the cookie with the key and invalidate the key when the Dave> session expires. Depends of course, on what you want to do with it. Again, way way way too much work. Please read the article. People overthink cookies. All you need for a cookie to do is to distinguish one browser from another --- that's it!! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
> Again, way way way too much work. Please read the article. People overthink
> cookies. All you need for a cookie to do is to distinguish one browser from > another --- that's it!! > Ok, I get it :) I'll read it, I obviosuly need to learn this! Thanks. Dave > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > -- Dave Bauer [hidden email] http://www.solutiongrove.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
In reply to this post by Randal L. Schwartz
> I am talking about ...a unique > cookie for each browser as a way of doing a session. In other words, session cookies. Seaside directly supports that. But, it has disadvantages, as have already been discussed. Nevin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
In reply to this post by Randal L. Schwartz
On Tue, Oct 28, 2008 at 1:57 PM, Randal L. Schwartz
<[hidden email]> wrote: >>>>>> "Dave" == Dave Bauer <[hidden email]> writes: > > Dave> This can be handled with cookies by creating a random, secure key on > Dave> the server for the session, and hashing the cookie with it, then you > Dave> can validate the cookie with the key and invalidate the key when the > Dave> session expires. Depends of course, on what you want to do with it. > > Again, way way way too much work. Please read the article. People overthink > cookies. All you need for a cookie to do is to distinguish one browser from > another --- that's it!! > I read it. It doesn't support the, "keep my logged in forever" feature that some sites use. Actually it does not support the, remember my username feature either. Of course, browsers do this for you, so maybe we shouldn't support that on the server side anyway. You would have to authenticate every time you close the browser. Otherwise it is much simpler since it handles all the complexity on the server side. So combining this identity cookie with URL session_id simplifies making sure session URLs can't be reused. It also allows you to reuse the "which browser is this cookie", if you combine it with the "this session belongs to this browser" feature. That is, you would have to check on the server side, which browser cookie belongs with which sessions. Then you could start a new session in another tab. Dave > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > -- Dave Bauer [hidden email] http://www.solutiongrove.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
>>>>> "Dave" == Dave Bauer <[hidden email]> writes:
Dave> I read it. It doesn't support the, "keep my logged in forever" feature Dave> that some sites use. Actually it does not support the, remember my Dave> username feature either. I explained in the article why I don't agree with such features. However, those are really server-side issues, not client-side issues. Really, the cookie only needs to distinguish a particular browser and then it's up to the application to decide what policy they want to make about that browser in accordance with the user's wishes. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
>>>>> "Randal" == Randal L Schwartz <[hidden email]> writes:
Randal> I explained in the article why I don't agree with such Randal> features. However, those are really server-side issues, not Randal> client-side issues. Really, the cookie only needs to distinguish a Randal> particular browser and then it's up to the application to decide what Randal> policy they want to make about that browser in accordance with the Randal> user's wishes. I guess, what I'm really trying to get across, is that all this writing and rewriting and deleting of cookies is rather wasteful. Write a cookie once to "brand the browser", and then leave it alone. You can implement any policy you want regarding authentication, session timeout, convenience, and so on, once you branded the browser. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
In reply to this post by Dave Bauer-3
> This can be handled with cookies by creating a random, secure key on > the server for the session, and hashing the cookie with it, then you > can validate the cookie with the key and invalidate the key when the > session expires. Depends of course, on what you want to do with it. > Anyone know how Seaside might detect whether or not the browser is even accepting cookies? Nevin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: sharing sessions through links..
|
|
Nevin,
It already does, see senders of #checkCookiesField for more detail, Cheers, -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Nevin Pratt Sent: Tuesday, October 28, 2008 11:16 AM To: [hidden email]; Seaside - general discussion Subject: Re: [Seaside] sharing sessions through links.. > This can be handled with cookies by creating a random, secure key on > the server for the session, and hashing the cookie with it, then you > can validate the cookie with the key and invalidate the key when the > session expires. Depends of course, on what you want to do with it. > Anyone know how Seaside might detect whether or not the browser is even accepting cookies? Nevin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
Boris Popov wrote:
> Nevin, > > It already does, see senders of #checkCookiesField for more detail, > > Cheers, > > -Boris > > Ah, OK! A sender of #checkCookiesField is WASession>>performRequest:, and the browser check seems to be done as follows: aRequest fields includesKey: self checkCookiesField Thanks! Nevin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
Nevin Pratt wrote:
> Boris Popov wrote: >> Nevin, >> >> It already does, see senders of #checkCookiesField for more detail, >> >> Cheers, >> >> -Boris >> >> > Ah, OK! A sender of #checkCookiesField is WASession>>performRequest:, > and the browser check seems to be done as follows: > > aRequest fields includesKey: self checkCookiesField > > Thanks! > > Nevin WASession>>useSessionCookie ^ cookiesEnabled and: [self application useSessionCookie] So, apparantly 'cookiesEnabled' is exactly what I want, and I don't have to do the browser check code I mention above. However, cookiesEnabled is set to 'false' under the following conditions: ((aRequest fields includesKey: self checkCookiesField) and: [aRequest cookies isEmpty]) ifTrue: [cookiesEnabled := false]. My question is: why do we care if 'aRequest cookies isEmpty'? Why should that have anything to do with whether or not the browser accepts cookies? Nevin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
In reply to this post by sergio t. ruiz
Because the test is such that it feeds browser a cookie and monitors if it receives it back, which would indicate browser supports them. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
In reply to this post by Nevin Pratt
On Tue, Oct 28, 2008 at 10:05 PM, Nevin Pratt <[hidden email]> wrote:
> Nevin Pratt wrote: >> >> Boris Popov wrote: >>> >>> Nevin, >>> >>> It already does, see senders of #checkCookiesField for more detail, >>> >>> Cheers, >>> >>> -Boris >>> >>> >> >> Ah, OK! A sender of #checkCookiesField is WASession>>performRequest:, and >> the browser check seems to be done as follows: >> >> aRequest fields includesKey: self checkCookiesField >> >> Thanks! >> >> Nevin > > WASession>>useSessionCookie > ^ cookiesEnabled > and: [self application useSessionCookie] > > > So, apparantly 'cookiesEnabled' is exactly what I want, and I don't have to > do the browser check code I mention above. > > However, cookiesEnabled is set to 'false' under the following conditions: > > ((aRequest fields includesKey: self checkCookiesField) > and: [aRequest cookies isEmpty]) > ifTrue: [cookiesEnabled := false]. > > My question is: why do we care if 'aRequest cookies isEmpty'? Why should > that have anything to do with whether or not the browser accepts cookies? Because if it accepted it, it should send it back to us. That's how we know whether they are supported. The check is a bit vague though. I just rewrote this in 2.9 to fix this problem, eliminate the creation of a second session for users who don't have cookies enabled, avoid having to check for _c on every request, and simplify the code a lot. The new behaviour is to redirect (to a continuation) with a session cookie and then check whether the session cookie matches the key in the URL. If not, we disable cookies for the session. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: sharing sessions through links..
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Oh, really?
How exactly does 'aRequest cookies isEmpty' do that? Nevin
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |