Thanks.
On Thursday, February 24, 2005, at 01:03 PM, Anthony M. Humphreys wrote:
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.
So right now, the Witango_UserReference is a session cookie, expiring when the browser is quit. I have a "Remember me" option that sets the expiration of the username/password_hash cookies to (effectively) never. So the change would actually synchronize the expiration of all three cookies.
I'm not clear what future problems I'd encounter, though it seems to me that keeping a userreferencecookie around would just be analagous to session hijacking.
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.
Maybe its as simple as using the userkey functionality already in Witango to append a hash to the Witango generated userreference.
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.
Actually, not yet. But good idea.
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
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
