[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.
>
Ok.
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
access?
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
SessionManager.
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.
NEVOW_SESSION="username=manlio&last_accessed=...&created=..."
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