On Nov 17, 2005, at 8:17 AM, [EMAIL PROTECTED] wrote:
Concretely: come to think of it I've never heard of a legitimate requirement other than "currently logged in user", which ought to be handled by another system anyway. As per CCE's previous emails, the system for initializing those and setting them up needs to be pretty flexible in terms of how and when login forms get displayed, but the use of cred is non-negotiable. We need a unifying cross- protocol abstraction.
Just some random thoughts on authentication. Userid information can come into the app in a wide variety of ways: REMOTE_USER var from *CGI, username from a verified SSL client certificate, HTTP authentication headers, session data from a previously filled out HTML login form, or something else completely. And no matter how I figure out who the user is, it has to be passed through to the rest of the site, including passing it on externally via *CGI outgoing REQUEST_USER. This I can see being done via the same mechanism used to include any other per-request data.
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.
James _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
