[Twisted-web] Sessions and Authentication for Web2

[glyph at divmod.com]

On Wed, 16 Nov 2005 13:48:12 -0500, "Clark C. Evans" <cce at clarkevans.com> wrote:

>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

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 use of getSession() is a mistake in every single case where it's used, except those in guard itself.  What resource you're viewing should implicitly represent what session you are talking to.  The whole idea of a session is entirely internal state that should not be exposed to the user.  What it amounts to is a rewrite of Python's argument-passing convention, used to pass stuff in an implicit, out-of-band way that's hard to document and impossible to test for.  All the discussion of Componentized and Context and all these other objects that are pretty much just different names for a free-form dictionary are indications that session-management == encapsulation violation, if it's exposed to the user.

Every session is associated with a user.  The representation of the session is the top of the resource tree.  If you need to persist information about the session, your resource tree should be pointed at a persistence system of some kind.  Perhaps the session manager should have better/more explicit support for simultaneous distinct sessions; in the case of anonymous sessions that would certainly be helpful.

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.

I am aware that this is not how "most" appservers do things.  However, "most" appservers also spawn hundreds of threads, and operate by putting conditional structures in a special-purpose scripting language into templates.  Add "exposed session interface" to the list of common design mistakes :).

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.

>  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

Hmm.  How did you get this idea?  Cred's design was specifically to facilitate challenge-response authentication.  That's why login() takes credentials and returns a Deferred.  The assumption is that the credentials object will encapsulate whatever facets of the user's connection are required to do the negotiation process.

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.

>  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?

Seems so to me.  Then again, the implementation specifics of the session manager are often pretty horrible.  This is another major reason that I think that the API for sessions should be kept as far away from the user as possible.

>  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.

web2 is itself experimental, and you are taking a risk by doing work with short-term deadlines on something unfinished.  Keep in mind that if these files are determined to be a bad idea later, they may be removed without warning and without regard for your project or deadlines.  You may want to work in a branch to provide yourself (and your employer) with some guarantee of stability.