[Twisted-web] [Nevow] about new guard in sandbox
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)
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
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
> 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
>> - as I can see the code in SessionManager._tick causes the log
>> "Session %r expired" to be issued two times.
>> - 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
> 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
> Also keep in mind that the most developed version of that code lies in:
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