That is an excellent idea. But I would fiddle a wee bit with the implementation.
But personally I would NOT use witango's userreference as my third item, not if I was going to expire it. I would not want to change the default session behaviour of Witango too much. It's dangerous, and can lead to future problems. If not for you, then for anyone else who would have to maintain that code after you. Personally, I would use the record id (or a "salted" hash of it, for "security purposes") from the login table as the third item (cookie) and expire it instead. copy the user's vars from their old session to the new session, or else reset their new session to the old userreference number to pick up the vars. BTW, I hope that the password is also "salted" before it's hashed and put into a cookies as well. It makes working out the password from the hash that much more difficult. "Salting" is the process of concatenating another string to the item to be hashed before it's hashed. Ideally it would be different for each username, but you could re-use the same "salt" for your application. That's how I have done it before, anyway. Anthony - ----- Original Message ----- From: "Bill Conlon" <[EMAIL PROTECTED]> To: "Witango-Talk" <[email protected]> Sent: Thursday, 24 February, 2005 14:53 Subject: Witango-Talk: thought experiment -- user reference cookie expiration > I'm pondering the implications of setting an expiration time for the > userreferencecookie, i.e., changing it from a session cookie to a > cookie with a fixed expiry. > > Here's why: > > My application permits persistent login (see > http://xmlx.ca/articles/625.aspx). Users are automatically logged out > by timeouturl, and automagically logged back in (after the timeout) by > username/password cookies maintained in their browser. Three cookies > -- userreference, username, password_hash -- provide everything that's > needed to maintain state while the user variables exist on the server, > and restore state if they've expired. This is done through a login > table that has a userreference, login state, and a foreign key to the > user table. > > Users can also manually log out, which marks the login table as such > and clears the username/password_hash cookies. But there's a problem > if the user mistakenly quits the browser without manually logging out. > Separate login logic enforces a single user session rule, i.e., a user > may only have a single userreference "logged in". When the browser is > quit and the user tries to login again, they are rejected, and have to > wait for their user variables to timeout, so they get logged out on the > server. > > If the all three cookies cookie had an expiry, when the browser was > re-launched, the same userreference cookie would still exist, and the > user either be still logged in or would be automagically re-logged in, > just as if they had left the browser open but there had been no > activity. > > Any thoughts? > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
