Valentino Volonghi aka Dialtone ha scritto:
On Mon, 31 Jul 2006 21:05:26 +0200, Manlio Perillo manlio_perillo@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=git...
and http://hg.stiq.it/index.cgi/stiq?f=eef00c91fd79;file=stiq/session.py;style=g...
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