On 6/17/09 2:52 PM, Hanno Schlichting wrote:
> On Wed, Jun 17, 2009 at 8:42 PM, Douglas Mayle<doug...@openplans.org> wrote:
>> I've been doing some testing of a new site, and I've used repoze.who
>> and repoze.what for authentication, and authorization respectively. I
>> did notice one unusual behavior with AuthTktCookiePlugin, however. If
>> I log in to the site, I receive an auth_tkt cookie. Once I have that,
>> I drop and recreate the database, as well as cleaning out any server
>> side session data. Having done all that, I imagine that my
>> environment is a clean slate, yet the predicate not_anonymous returns
>> true, even though I haven't logged in yet. That's because the
>> credential data coming from client cookie is entirely trusted. I was
>> imagining some sort of collaboration between the client and server,
>> such that the client cookie was just an index into a session.
> AuthTkt doesn't contain a server side session storage or validates
> against such a thing. It is based on a "secret string" and the userid
> alone per default. You can add issuing IP address or timestamps to the
> mix, but both have some drawbacks in certain situations.
> I imagine you might have set up the secret either in code or a
> configuration file and didn't change it. Thus the issued cookies still
> contain valid authentication information.
There is a flaw here in repoze.who using the auth_tkt plugin. r.who should
ensure, upon receipt of an auth tkt identity, that the user implied by the
userid in the auth tkt still "exists".
There is currently no API that allows us to do so without providing a full set
of credentials (including a password) to an IAuthenticator plugin, so the
auth_tkt sets the repoze.who.userid within the identifier plugin (creating a
This is a design bug that may be a security issue; I will try to fix it in the
next major release of r.who.
Repoze-dev mailing list