[Zope-PAS] [RFC] Extending CookieAuthHelper
tino at wildenhain.de
Tue Nov 16 08:17:21 EST 2004
On Tue, 2004-11-16 at 13:18, Chris Withers wrote:
> (belately sending again in the hope that the list doesn't bounce it again)
> Hi Jens,
> Jens Vagelpohl wrote:
> > In a nutshell, credentials should not be stored in the cookie itself.
> > The proposed changes involve storing a simple key, or "ticket", in the
> > cookie and storing the credentials in the user's session under that
> > ticket key.
I got the impression, the sessionid (for the session :-) is exactly
such a ticket. So what would we get with another key?
> I think Lennart Regebro already has some nice code to do this bit...
> However, it would be nice if this plugin could optionially use a storage
> mechanism other than the user's session, in cases where even more
> security is required (being able to specify that the cookie should only
> be sent by https, hashing with the user's ip address, etc)
Isnt this the job for BrowserIdManager anyway?
> > Also, the lifespan of the cookie should be configurable on the plugin
> > and there should be a "logout" method that can be called from user
> > space/untrusted code to effect cookie expiration.
I think logout (and forced login) should be there for all auth
mechanism, even if they dont really support it.
> The place on the server should also have the same expiration code. ie:
> when you expire the cookie, the server side session should also be
> removed, so even if someone has stolen a cookie, they can't use it...
> > Like I said, this could be done by extending the CookieAuthHelper or by
> > basing a new plugin on it. What are peoples' preferences or suggestions?
> I'd prefer to see CookieAuthHelper get better, rather than addign a new
But I might have mixed up the case. There is CookieAuth on one
side and SessionAuth on the other. With SessionAuth, we could
indeed store the credentials in the session and use all the
mechanism yet in place to get the session by ID, timeout and so
on ;) (If the user really wants a timeout!)
With CookieAuth I dont think it should use SESSION, because if the
admin uses CookieAuth instead of Session out, (s)he does it by
purpose. So real CookieAuth has only the option to store the
credentials in the cookie. They can be hashed with some kind
of configureable salt to get just a little bit more security.
But still this method is very similar to BasicAuth, not better
but not worser.
Depending on the way the session is established, there is also
a way to use the session-id as temporary credential. I've done
this in the past with database supported session, where a logout
or a login with same user credentials disabled the session-key
and therefore the temporary access with it.
So this wasnt really a session-based auth but a "along the session
auth" or so ;)
More information about the Zope-PAS