Valentino Volonghi aka Dialtone ha scritto: > On Mon, 31 Jul 2006 21:05:26 +0200, Manlio Perillo > <[EMAIL PROTECTED]> 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 _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
