On Thu, Nov 17, 2005 at 06:47:27AM -0500, glyph@divmod.com wrote:
I'm not sure what "completely separate" means in this context. I don't think I agree, although I'm not sure about the specifics of the implementation. I do think that there should be no public session-management API divorced from authentication though.
The point of separation is: web services don't need session management but they might require authentication. And session management can be required without requiring authentication. Having separate filters for session management and authentication should be possible without many problems using filters. Currently the filter signature is the following (none of the below functions exist yet): def sessionfilter(req, res, ctx): # do session handling here def authenticationfilter(req, res, ctx): # do authentication handling here Then setting these as explicit filters in the interface will allow to have separate session and authentication handling without even having them know of each other existence, which is a good improvement IMHO. The logic I proposed for the session management is the following: - Request arrives at the server - sessionfilter looks for cookie/urlsegment/whatever. - there is a cookie, search for the corresponding session in the sessionstorage. - there is a session then: retrieve the session from the session storage (this returns a deferred and then adds as callback the rendering of the page). - there is no session then: create a new 'proxy' session and make the rendering buffered. - there is no cookie information then: create a new 'proxy' session and make the rendering buffered. - the page is rendered (and the user data in the session might be modified in some way). - if the session data was modified: - if the session is a proxy object: during the first modification it will create a local session object and marks it as touched. - if the session is a real session object: mark it as touched. - if the session data was not modified: ignore - very end: if the session was touched commit the changes back in the session storage. There might be inconsistencies in the above flowgraph of course, I wrote this down without thinking too much about current APIs or limitations. It might be too much complicated or whatever, the only purpose is to discuss how to do this :). The authenticator logic is similar: - request arrives: gather credentials from the request - call portal.login() - if the credentials are not met return a FORBIDDEN responsecode and blabla - if the credentials are met: return the adapted resource returned by portal and start the locateChild on the remaining segments on that resource (? judging from the current API of the filters this can be hard though to implement in this way, since the filters are called after the resource has been located IIRC).
As JP stipulated, this all *must* go through cred. A separate session interface is unacceptable. It is already hard enough managing the insanity of HTTP in a multi-protocol server.
Indeed. Totally agreed.
All that said, I don't think that your requirements are wrong, and I do think that the implementation specifics of the Nevow session initiation implementation are pretty bad, and they are mostly my fault.
We are trying to find a new way to do things without boundaries to old APIs and such :). So many changes have to be made that discussing with backwards compatibility in mind is just a waste of time IMHO. It is good if we could just brainstorm some stuff and bash each other. :)
Again, this may be a place that Nevow's current session-initialization strategy falls down; IIRC it wouldn't allow for that Deferred to be fired by multiple different web-page hits, since it is a Deferred which is expected to itself return a Resource. That's a limitation of guard though, not cred.
This is interesting to integrate with the filters idea then and might be useful (given the problem identified above). Hope everything makes some sort of sense. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com http://weever.berlios.de