If you touch SessionDBI for every request, why don't go directly to the Basic Authentication ? Using AuthCookie would 1) slow down the authentication process (because an extra MD5 hash calculation) and 2) drop off 10% of users who have disabled the cookie.
One of the nice features in the AuthCookie, and ticketing authentication systems in general, is that the ticket is self-consistent. So one can check if the ticket is valid without calling any DBI (instead, it calculates a MD5). Repeating SELECTs/UPDATEs to DBI does hurt much the performance of a high traffic site. My 2 cents. Peter Bi [EMAIL PROTECTED] >>>>.......................... > If someone comes in with an old active session (assuming it's not > expired) AuthCookie examines the MD5 hash and says "everything matches > up, you may proceed". I need to add a step here to say "if newer > session for user exists, kill this one". But you've just given me a > great idea! When the old session comes in, there will still be data in > the session (because the new session is using it - sessions are keyed by > user id, not session id). So I can't rely on an empty session data to > be the clue. BUT - I can store the session key that generated this > session data in with the session data, and try to match those up. I > like it. This will work, I think. Thank you. =) Why do I use the user > id instead of the session id for the session key? Because it makes the > code easier for other developers ("a user will always have a session > with the key $r->connection->user") and that gets passed around > automatically rather than me having to expose the developers to the > AuthCookieDBI cookie directly. I just find it easier to rely on > $r->connection->user to always be the session key. > >>>>>>