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.
>
>>>>>>
