George Lee wrote:
> Laurence Rowe <l <at> lrowe.co.uk> writes:
>
>>> An alternative would be:
>>> * Each time someone logs in:
>>> - Generate a new secret s.
>>> - Store that secret, the user id, and an expiration time (if desired) in
>>> a persistent dictionary with the user id's as key values.
>>> - Store that secret (or a hash of the secret and user id) in a cookie.
>>> * Each time someone logs out:
>>> - Based on the cookie value, invalidate the secret
>>> * On each request
>>> - Check to see that the cookie value corresponds to a stored secret/user
>>> id pair that hasn't expired yet
>>> - Extend the expiration time
>>>
>>> I think because this uses persistent data to store information, this would
>>> avoid some of the issues with SessionCrumbler from the PLIP #48 proposal,
>>> including issues with inconsistency across Zope restarts and multiple ZEO
>>> clients.
>>>
>>> Does this sound reasonable? I'm somewhat experienced with the tech knowledge
>>> here but not an expert at it, so hoping to understand if this would work.
>> We should avoid writing to the database at login as it causes conflict
>> errors.
>
>
> Can you explain this more?
>
> Would this be the case with writing to the database at logout as well?
It would be an issue at logout too. Writing to the database slows things
down and should in general be avoided for all read-only operations.
>> I would like to move to the mod_auth_tkt system for signing
>> authentication cookies. I have this implemented in a branch [1] of
>> plone.session
>
> Looking at the branch --
>
> (1) One downside: If there is no timeout set, then even if a user logs out, the
> old cookie value could continue working. If it's possible to write to the
> database at logout, one possibility is to write to the database a list of
> revoked cookie _ac values.
>
> (2) One thing that could be nice is for a user to be able to invalidate their
> past sessions (similar to how in Gmail a user can log out all other sessions).
> Currently and with this branch, because all users share the same secret, no user
> could do this without invalidating everybody else's sessions as well.
If we stored secrets per user then we would need to load the secret to
validate the cookie at every request (except for the caching, see
below.). This would slow things down further. Gmail shows user specific
data, so it needs to load user specific information anyway.
> (3) Also, right now the cookie will expire after timeout passes, even if there
> is activity in the meantime. Could authenticateCredentials change to
> re-timestamp the cookie if the authentication passes? (Implementing the list of
> revoked authentication tokens in (1) would be a little more involved in this
> case, but still doable. For instance, make the cookie contain a hash involving
> the original timestamp, plus another hash involving the current timestamp -- and
> on logout, revoke all cookies with the original timestamp/userid combination).
mod_auth_tkt in apache can issue an updated cookie when you reach a
proportion of the timeout value. I didn't implement this yet because the
acl_users caching complicates matters - it caches a authenticated
credentials so the session plugin is not invoked every request. On
systems I have this installed I let apache update the ticket.
Laurence
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
