[Twisted-web] HTTP-AUTH for web2 / Kudos on web2's operation

[glyph at divmod.com]

On Fri, 18 Nov 2005 02:12:42 -0500, James Y Knight <foom at fuhm.net> wrote:

>On Nov 17, 2005, at 8:17 AM, glyph at divmod.com wrote:

>Just some random thoughts on authentication. Userid information can  come 
>into the app in a wide variety of ways: (...) it has to 
>be passed through to the rest  of the site, including passing it on 
>externally via *CGI outgoing  REQUEST_USER.

>I find that operation to be conceptually separate from the operation  of 
>"given an authenticated userid, give me his toplevel Resource".  Also  
>completely separate is "gimme a new session". That current guard  merges all 
>three together into one operation is where I've always had  trouble with it. 
>Sometimes the three intersect, sometimes they don't,  it depends upon the 
>application.

There are definitely at least 2 separate levels of abstraction here.

At one level, you are dealing with HTTP objects.  You have resources, and you have essentially meaningless strings that allegedly represent usernames (or form fields) which must be passed to other things which require access to a username.  This is entirely a wiring problem, and the solution is irrelevant to application developers.  No request-specific application data passing APIs are required for this because all the information you just described is part of each HTTP request itself.

At another level, you are authenticating a user to an application written using Twisted.  The way Twisted applications should do this is using cred, and the web way to use cred is with guard.

Application authors are welcome to use the HTTP protocol and resource model traversal code to do something else, if their application requires it.  However, providing discrete, optional APIs for session-creation, credentials passing, and authenticated application object access would be tedious, confusing, and ultimately would break any attempts to integrate with cred objects that were not originally designed for HTTP.

Let me try to clear up a few misconceptions about cred and guard that seem to have crept into the discussion here.

- Resources are lightweight.  You can have a top-level resource object which controls your session.  In other frameworks, such an object is called a "controller" for good reason.  There is no reason to have a separate 'session' object. What else does a "session object" do, anyway?  Store a dictionary of random keys to arbitrary objects?  Namespace conflict and cruft accretion issues abound once you start seeing "the session" as a tiny object you can stick bigger things to.  Your top-level resource is your application's controller, and it carries both session state and authority.

- Authentication does not imply authorization.  You don't have to log in as a user with a username to use the guard style of authentication.  You can implicitly authenticate as the anonymous user, which gives you a top-level resource, which is your session.  Again, resources are lightweight.  It needn't do anything but trivially wrap the shared resource at the top level.  

  - If you are getting a LOT of hits, and individual persistent objects for sessions really are too heavyweight for you, you don't need to use guard to access the static parts of your site.  guard's SessionWrapper doesn't need to live at /, it just needs to be somewhere persistent.

- Guard is a higher-level abstraction that is based around resources.  It shouldn't be built into the request at all.  There is no need to pay its cost if your application is doing something else.

- Guard should be flexible enough to allow for several different kinds of authentication mechanisms, not simply the HTTP-form-post mechanism it provides today.  It should let resources create credentials and pass them to the realm in whatever way makes the most sense for the desired user-experience.  It is currently extremely inflexible in this regard and I think it's just broken.

- Guard should allow the session to be pluggable, using cookies, digest authentication, headers, tunable timeouts, etc.

I am open to suggestions as to how to do cred-style authentication with an interface that isn't IResource, if something else makes more sense there.  I am doubtful but not implacable.  However, web2 is definitely going to include something an awful lot like guard before its final release.  Twisted is unfortunately thin on unifying abstractions currently, and cred is the best one we have.  The alternative to cred-style authentication in web2 is a new, better unifying abstraction plus a rewrite of the relevant portions of at least SIP, IMAP4, POP3, SMTP, Telnet, SSH, FTP, and IRC.  This is what I meant by "cred is non-negotiable".