Bill, Why prevent two simultaneous logins for the same user? In theory this shouldn't cause any problems, however, I can see why you might want to control this, however instead of not allowing the second login, why not let it pickup the first login where it left off? Unless you are dealing with more than one person using the same account, this should be acceptable.
Also, depending on how much user information you are supporting for your logged-in state, you might want to try saving your user data in the database, and then restoring the last saved state regardless of when the login occurs - minutes, days, or months later. Personally, I don't like web browsers or web sites to remember my state, I want to login again each visit, and give my password again. Sure, it can set a cookie so I don't have to type my username again, but not the password. This is especially true if credit card or auto-ordering systems are on your site. Lastly, you should not use the Witango UserReference as anything tied to your users. You should assign another identifier using almost any other means. There are a few reasons for this, one, USRs can be duplicated over a large span of time, because the timestamp is part of the hash they can cycle rather close, and possibly duplicate (I don't know what the statistical probability is). Also, in some setups, certain information in the USR can become invalid, and prevent the USR from working properly. I'm not saying that either of these things would affect you, but in general, it's best to let the USR do its job, and you do yours with a separate value. Robert -----Original Message----- From: Bill Conlon [mailto:[EMAIL PROTECTED] Sent: Thursday, February 24, 2005 2:54 PM To: Witango-Talk 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
