session and cookies?
Locked
 
|
Hi list!,
Please consider this situation: A user enters the site (a WASession is created) then the user logs in (a User model object holding some information is stored in the session, in an instance variable), does some work, and: 1-leaves the page, i.e. he goes to another web site 2-close the tab holding the page 3-close the browser 4-logs out and then leave. Whenever the user re-enters the site, another WASession is created (AFAIK) which hasn't got the user information (the user instance variable is nil). This is ok in the case 4, because no user is logged in. But in the cases 1-3, when the user comes back, the system should recognize him and his information should be available in the current session because, actually, he is still logged in. If the original session hasn't expired, it could be reassigned so the user information is available. Another solution would be working with another session but setting its user variable to the one the original session had. so.. the question would be.. What is the best way to achieve this, cookies maybe? If so, should I consider session-only-cookies vs permanent cookies? (because of the difference between cases 1,2 and case 3) Thanks a lot, Leandro _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On 8/30/07, Leandro Perez <[hidden email]> wrote:
> Hi list!, > Please consider this situation: > A user enters the site (a WASession is created) then the user logs in (a > User model object holding some information is stored in the session, in an > instance variable), does some work, and: > 1-leaves the page, i.e. he goes to another web site > 2-close the tab holding the page > 3-close the browser > 4-logs out and then leave. > > Whenever the user re-enters the site, another WASession is created (AFAIK) > which hasn't got the user information (the user instance variable is nil). > This is ok in the case 4, because no user is logged in. But in the cases > 1-3, when the user comes back, the system should recognize him and his > information should be available in the current session because, actually, he > is still logged in. > > If the original session hasn't expired, it could be reassigned so the user > information is available. Another solution would be working with another > session but setting its user variable to the one the original session had. > > so.. the question would be.. > What is the best way to achieve this, cookies maybe? > If so, should I consider session-only-cookies vs permanent cookies? (because > of the difference between cases 1,2 and case 3) > There are two things to consider here. 1) you want to recognize the user, if they have previously logged in and clicked some sort of "remember my login" box. 2) you don't want to have the session last forever in case there is a login on a shared computer So you need a session cookie that expires after say 15 mins. On every request if the cookie has not expired, renew the timout on the cookie for another 15 mins. After 15 mins you could recognize the user, but ask for the user to enter their password again, to confirm their identity. It is usually friendly to allwo the user to access public resources without requiring them to type the password again. You'd just ask for the password if they attempted to view some private data, or perform an action. Dave > Thanks a lot, > Leandro > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Dave Bauer [hidden email] http://www.solutiongrove.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Leandro Perez-2
In my opinion, the best practice for "remember me" functionality, is to
store the encrypted/hashed username and password on the cookie, then when the user returns to the site, try and log them in after decrypting or comparing hash values, instead of having the user enter them manually. Everything else should be instanced as per a "normal" login from then on. If you have session specific information, then the session has ended.. thus the new session will lose that information. However, it is possible to store the session ID in the users cookie, so if the session has not expired, and you override the cookie timeout, it would be possible for the user to return to the same session (and also possible to return to the same session from a different machine - so be warned of hijacking!) Hope this helps, John www.pinesoft.co.uk Leandro Perez wrote: > Hi list!, > Please consider this situation: > A user enters the site (a WASession is created) then the user logs in (a > User model object holding some information is stored in the session, in an > instance variable), does some work, and: > 1-leaves the page, i.e. he goes to another web site > 2-close the tab holding the page > 3-close the browser > 4-logs out and then leave. > > Whenever the user re-enters the site, another WASession is created (AFAIK) > which hasn't got the user information (the user instance variable is nil). > This is ok in the case 4, because no user is logged in. But in the cases > 1-3, when the user comes back, the system should recognize him and his > information should be available in the current session because, actually, he > is still logged in. > > If the original session hasn't expired, it could be reassigned so the user > information is available. Another solution would be working with another > session but setting its user variable to the one the original session had. > > so.. the question would be.. > What is the best way to achieve this, cookies maybe? > If so, should I consider session-only-cookies vs permanent cookies? (because > of the difference between cases 1,2 and case 3) > > Thanks a lot, > Leandro > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
John wrote:
In my opinion, the best practice for "remember me" functionality, is to I agree with this, but shouldn't you consider the problem of a different person accessing the computer after the real user has left? to tackle this problem something would have to be done, a possible solution would be what Dave Bauer said, just to ask for a password when the user returns I'll have to learn how to create cookies and to store information on them. Any tips about encryption? Everything else should be instanced as per a "normal" login from then However, it is possible to store the session ID in the users cookie, so How do I get the session id and retrieve the session using this id? in which place do sessions dwell? Hope this helps, Thanks a lot John and Dave! _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> I'll have to learn how to create cookies and to store information on them.
> > Any tips about encryption? On OpenACS (ancient web toolkit) there is a pool of secret tokens that are generated by the server. These are used to digitally sign the values in the cookies. Note, the values are not secure unless you use HTTPS in this scheme. You can make a cookie "secure" and it will always be transmitted over HTTPs. Of course the values are on the computer, that's why you shouldn't put anything secret IN the cookie. You could also use someting like ssha-1 to encode the values before setting the cookie. Here's the code where I am getting the design ideas from if you are interested. it is written in Tcl but should be reasonbly readable. http://cvs.openacs.org/cvs/openacs-4/packages/acs-tcl/tcl/security-procs.tcl?rev=1.44&view=markup Good luck. > > -- Dave Bauer _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hello Seasiders,
Squeak has the #initialize pattern on Object - but VisualWorks doesn't. I'm not sure about Gemstone or Dolphin. Aside from the argument that may be we should have that pattern too - in the interest of code portability, what is the best approach here. For example, WAHtmlBuilder (essential for getting all the tests to go green) expects to have the #initialize pattern on Object. Is there any other code in Seaside that does the same? Would it be appropriate to not assume that pattern in the Seaside code for portabilities sake? Cheers, Michael _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2007/8/30, Michael Lucas-Smith <[hidden email]>:
> Hello Seasiders, > > Squeak has the #initialize pattern on Object - but VisualWorks doesn't. > I'm not sure about Gemstone or Dolphin. > > Aside from the argument that may be we should have that pattern too- in > the interest of code portability, what is the best approach here. Acutally this issue like many others is covered in the Seaside coding conventions: http://www.seaside.st/community/conventions I just simply forgot is in this case. Seaside2.8a1-pmm.463 should fix this. > For example, WAHtmlBuilder (essential for getting all the tests to go > green) expects to have the #initialize pattern on Object. Is there any > other code in Seaside that does the same? Yeah, a hell of a lot. Ceck out all the implementors of #new and initialize. Cheers Philippe > Would it be appropriate to not assume that pattern in the Seaside code > for portabilities sake? > > Cheers, > Michael > _______________________________________________ > 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: Object new initialize
|
|
Philippe Marschall wrote:
> 2007/8/30, Michael Lucas-Smith <[hidden email]>: > >> Hello Seasiders, >> >> Squeak has the #initialize pattern on Object - but VisualWorks doesn't. >> I'm not sure about Gemstone or Dolphin. >> >> Aside from the argument that may be we should have that pattern too- in >> the interest of code portability, what is the best approach here. >> > > Acutally this issue like many others is covered in the Seaside coding > conventions: > http://www.seaside.st/community/conventions > > I just simply forgot is in this case. Seaside2.8a1-pmm.463 should fix this. > figured if it were a common problem, it would have been happening everywhere. Good to see it's covered in the conventions :) Michael _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Object new initialize
|
|
In reply to this post by Michael Lucas-Smith-3
On 8/30/07, Michael Lucas-Smith <[hidden email]> wrote:
> Squeak has the #initialize pattern on Object - but VisualWorks doesn't. > I'm not sure about Gemstone or Dolphin. Dolphin has Object>>#initialize with an empty method body (answers receiver). However #new with use of #initialize is only defined in Model class, and some others, but not in Object class. Regards, -- Esteban A. Maringolo [hidden email] _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Michael Lucas-Smith-3
2007/8/31, Michael Lucas-Smith <[hidden email]>:
> Philippe Marschall wrote: > > 2007/8/30, Michael Lucas-Smith <[hidden email]>: > > > >> Hello Seasiders, > >> > >> Squeak has the #initialize pattern on Object - but VisualWorks doesn't. > >> I'm not sure about Gemstone or Dolphin. > >> > >> Aside from the argument that may be we should have that pattern too- in > >> the interest of code portability, what is the best approach here. > >> > > > > Acutally this issue like many others is covered in the Seaside coding > > conventions: > > http://www.seaside.st/community/conventions > > > > I just simply forgot is in this case. Seaside2.8a1-pmm.463 should fix this. > > > Thanks. I was a little surprised, as I hadn't seen this previously. I > figured if it were a common problem, it would have been happening > everywhere. Good to see it's covered in the conventions :) That's mostly thanks to Michel Bany. For a long time he helped increase the portability by making us aware of our "sins" and fixing unportable stuff. Cheers Philippe > Michael > _______________________________________________ > 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 |
|
|
In reply to this post by Dave Bauer
Dave Bauer wrote:
Thanks a lot Dave, I'll have a look of it asap! Leandro _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Philippe Marschall
Hi, I was reading the coding conventions which says, "every root class that implements #initialize must have a #new on the class side" and I was wondering, if the following is implied on subclasses of WAComponent and WATask:
class methods: WRONG new ^super new initialize
CORRECT new ^self basicNew initialize If the above is correct, is this the case for classes that are subclassed from Object? Thanks in advance,
-Conrad On 8/31/07, Philippe Marschall <[hidden email]> wrote: 2007/8/31, Michael Lucas-Smith <[hidden email]>: _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Michael Lucas-Smith-3
I am always using "^ self basicNew initialize". With every type of
objects. Cheers, Oleg _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Conrad Taylor
2007/9/6, Conrad Taylor <[hidden email]>:
> Hi, I was reading the coding conventions which says, "every root class that > implements #initialize must have a #new on the class side" and I was > wondering, if the following is implied on subclasses of WAComponent and > WATask: > > class methods: > > WRONG > > new > ^super new initialize > > CORRECT > > new > ^self basicNew initialize > > > > If the above is correct, is this the case for classes that are subclassed > from Object? The rules there only apply to framework code and if you want your own code to be portable. If you are happy if your code only works with dialect X then you can safely ignore them. Root class means root class in Seaside. So if you subclass Object you need to implement it but if you subclass WABrush then you don't. Cheers Philippe > Thanks in advance, > > -Conrad > > > On 8/31/07, Philippe Marschall <[hidden email] > wrote: > > 2007/8/31, Michael Lucas-Smith <[hidden email] >: > > > Philippe Marschall wrote: > > > > 2007/8/30, Michael Lucas-Smith <[hidden email]>: > > > > > > > >> Hello Seasiders, > > > >> > > > >> Squeak has the #initialize pattern on Object - but VisualWorks > doesn't. > > > >> I'm not sure about Gemstone or Dolphin. > > > >> > > > >> Aside from the argument that may be we should have that pattern too- > in > > > >> the interest of code portability, what is the best approach here. > > > >> > > > > > > > > Acutally this issue like many others is covered in the Seaside coding > > > > conventions: > > > > http://www.seaside.st/community/conventions > > > > > > > > I just simply forgot is in this case. Seaside2.8a1-pmm.463 should fix > this. > > > > > > > Thanks. I was a little surprised, as I hadn't seen this previously. I > > > figured if it were a common problem, it would have been happening > > > everywhere. Good to see it's covered in the conventions :) > > > > That's mostly thanks to Michel Bany. For a long time he helped > > increase the portability by making us aware of our "sins" and fixing > > unportable stuff. > > > > Cheers > > Philippe > > > > > Michael > > > _______________________________________________ > > > Seaside mailing list > > > [hidden email] > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > _______________________________________________ > > Seaside mailing list > > [hidden email] .org > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > _______________________________________________ > 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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |