[Twisted-web] [Nevow] about new guard in sandbox

Manlio Perillo manlio_perillo at libero.it
Tue Aug 1 03:40:20 CDT 2006

Valentino Volonghi aka Dialtone ha scritto:
> On Mon, 31 Jul 2006 21:05:26 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> Hi again.
>> I have read the draft implementation of guard in Valentino's sandbox and
>> I like it.
>> However I have some questions:
>> - why the ISessionMenager interface does not include a name attribute
>>  (since the default Session class uses the private _name)?
> The reason why it misses the name in the interface is that it's not
> meant to be accessible from the outside. It's a pretty important
> internal detail in _this_ SessionManager implementation. There might be
> many other ways to deal with distributed session rather than simply
> using name attribute on the sessionmanager and ISessionManager ought to
> be as generic as possible.

Now I also understand your concern about identifying who creates a session.

Only a question: in the example you only store (in the database)
"permanent" sessions.
Not sure about this, but I think that all sessions, except those for
anonymous access, should be persisted in the database (to avoid problems
in a distributed system).

>> - why Session.authenticatedAs has to be a property?
> Because I wasn't able to find a better name that was somewhat compatible
> to using an explicit get/set. And because it's cleaner IMHO.

Not sure. ;-)

>> - I think that there is no need to store tha password but only the
>>  username, so authenticatedAs -> avatarID
> Not really... Authentication is rerun for each request because the
> avatar is not saved and this is the most important detail of that new
> guard. 

Here I'm not sure to understand.
You mean that the avatarID (username) is not stored in the session
object? This seems not the case.

Another thing: is it really necessary to create a session for anonymous

And what about to store the authenticated username in the context
(instead of hacking on the site.makeSession)?

> Also the avatarId is not available in guard because it's a cred
> implementation detail. And the avatarId might be any object. But I'm
> open for alternative solutions.

>> - what's the use for the guard attribute in Session?
> It's explained in the docstring of loggedIn (somehow). It's because it
> makes
> it easier to access the guard that created the session.
>> - I think that ISessionManager should not have the loggedIn method.
> Why? It allows to change how the application should react to a successfully
> logged in session without going through guard code overriding a
> callback, of a very big method, defined as a closure. IMHO it's a lot
> cleaner to have it this way unless your reasons are sensible.

I'm against this because I whould like to have a realy reusable

The SessionManager is really an useful class and it should not depend
over a SessionWrapper (because I can choose to not use a SessionWrapper
al all).

>> - as I can see the code in SessionManager._tick causes the log
>>  "Session %r expired" to be issued two times.
> True.
>> - what's the use for mind in a web authentication?
> I have no idea. There might be a usage, why should you make it impossible
> to have a usage of it?
>> - why credInterface is a variable? It can be something different from
>>  IResource?
> iweb2.IResource? Anyway this is absolutely not a valid concern it's simply
> a refactoring to allow changing that interface from application level
> code (again without the need to dig through the code).

Yes, this is not a valid concern but I like to have code that is as much
symple as possible, where I don't have to try to understand every
statement. ;-)

> [...]

> Also keep in mind that the most developed version of that code lies in:
> http://hg.stiq.it/index.cgi/stiq?f=b9671c61c96b;file=stiq/guard.py;style=gitweb
> and
> http://hg.stiq.it/index.cgi/stiq?f=eef00c91fd79;file=stiq/session.py;style=gitweb

Ok, thanks.
Now I'm trying to learn as much as possible about web authentication
because it seems that it does not exists an unique solution.

As an example a valid alternative to store state in the server is to
store it in the cookie.


of course using some cryptography.

This has the advantage to work "as is" in a distributed system and to
not depend on the number of sessions/users.

Thanks and regards  Manlio Perillo

More information about the Twisted-web mailing list