[Twisted-web] Sessions and Authentication for Web2

[Clark C. Evans]

Hello.  I am in the middle of porting my application(s) to web2, 
and it seems that general authentication and session handling is 
not yet implemented.   My requirement is rather simple:

  1. When the user connects to my system (via HTTPS), I check for
     a cookie that indicates their server-side session.  If they
     have a session active, I touch() the session so that the 
     expiration date is pushed out.

  2. If the cookie does not exist, or the session has expired,
     then I send them through one of 3 authentication mechanisms
     depending on either their IP, a query argument, or what
     resource they are trying to access.
    
     a) If they are coming from a YALE IP address and have not
        explicitly asked for HTTP Digest authentication, I use the CAS
        authentication mechanism: http://www.yale.edu/tp/auth/cas20.html
    
     b) Else, if they are viewing a limited "semi-restricted" set of
        resources, I use another custom challenge-response mechanism
        that is similar to CAS (but slightly different)

     c) Otherwise, I use HTTP Digest Authenitication.

     All of these methods require that the request be cut short,
     and either a 401 is returned, or a HTTP Redirect (for CAS).

  3. Once I have an authorized user; I create a session for them,
     and set a 20 minute timeout.  I might have multiple requests
     active for the same session.

Once I have a session, I need a few things:

  1. A way to getSession() from a given request; in particular,
     most resource authorization is based on the user's identity.

  2. Request specific storage of temporary working data so that
     requests in-progress can accumulate results before the
     response is generated.

  3. Session specific storage, so that information about the user's
     context can be maintained.  This needs to be synronized with
     a database server since the Session may be shared across
     multiple servers.

  4. A JobQueue for that particular Session.  Many queries take
     a long time to run; and incremental results and/or failure
     notices need to be managed between each request.

  Of these requirements, #1 is most important, and #4 is a wish-list
  item for the next version of my application.

We had a chat on IRC today, and a few random notes/ideas emerged:

  a) There was a strong preference to keep Session and Authentication
     completely separate.  Currently Nevow's Guard mixes the two and
     thus is overly complicated and non-modular.  Nevow also uses
     Componentized, which is depreciated (in favor of... ?)

     http://divmod.org/trac/browser/trunk/Nevow/nevow/guard.py
     http://divmod.org/trac/browser/import/Nevow/sandbox/mg/guarded/guard.py

  b) Besides Nevow's GuardSession, there are a few other session
     implementations besides the older twisted.web implementation.
     A requtil.py in web2 seems to be a straight-forward port of
     tw.web's sessions.  Quixote also has a session manager,
     http://quixote.idyll.org/session2/ which is licensed to steal.

  c) Exarkun expressed a strong (ok, mandatory) preference for the
     use of tw.cred in any Authentication solution.  However, it was
     noted that tw.cred does not allow for challenge-response 
     authentication mechanisms (which all of mine are).  Specific
     examples were noted: twisted.protocols.sip, SASL, OTP

  d) There was talk that the Session manager should actually be
     a filter on the Response object; so that it can rewite paths
     and/or inject cookies as needed before the response is sent.
     This seems a bit complicated, no?

  e) I can probalby help in some ways, but I'm not a Twisted expert.
     I could continue to collect requirements and post; but I have
     short term deadlines (as usual).  If you wish I could put two
     files in twisted.web2, marked 'experimental':

        session.py    This would contain session manager, how ever
                      it is eventually implemented.

        guard.py      This would contain the gule to link tw.cred
                      to web2.

      I prefer an iterative; implement the simplest solution first,
      and then grow it as needed approach (with clear marks on 
      instability).  I wouldn't mind owning these two files and
      collecting feedback, etc.  

Anyway, thanks for listening.  Any thoughts as to how to best proceed
would be very welcome.

Kind Regards,

Clark

P.S.  For now, I'm hacking my own session and auth code.
      There is a requtil.py in web2 which is a stab at sessions,
      and both David Reid and I have HTTP Auth code in our sandbox.