On Fri, 18 Nov 2005 02:12:42 -0500, James Y Knight <[EMAIL PROTECTED]> wrote:
On Nov 17, 2005, at 8:17 AM, [EMAIL PROTECTED] 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".
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
