[Twisted-web] Sessions and Authentication for Web2

[Valentino Volonghi aka Dialtone]

On Thu, Nov 17, 2005 at 06:47:27AM -0500, glyph at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20051117/90026ff5/attachment-0001.pgp