Thx. On Thursday, February 24, 2005, at 01:19 PM, Robert Shubert wrote:
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.
It's a hosted application service (think salesforce). Functionally, there's no problem allow people to use the same login, and it was very convenient to do so during testing. But this was the easiest way to enforce per-user payment.
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.
Actually, there's very little state that needs to be saved -- really just the user/pass info for the automagic login. There are a few things, but alas a bug in the urltimeout prevents me from actually saving it (user variables actually timeout before timeouturl is triggered) contrary to the docs.
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.
Agreed. Wouldn't do this for billing or medical records.
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.
Good point. But generating my own unique key to replace <@userreference> is not trivial either. I seem to recall there was a thread on this point two years ago. I'll look into it.
I'm still hoping to continue using the userreferencecookie, whatever its (hopefully unique) value, as the userkey to synchronize client and server interactions.
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
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
