Jorge Godoy wrote:
> "Damjan" <[EMAIL PROTECTED]> writes:
>
>> Exactly, but TurboGears needs to make use of it... for example the
>> decorator:
>> @identity.require(identity.in_group("admin"))
>> would use the WSGI environ['REMOTE_USER'] to create a User object and
>> check it's permissions..
>
> Hmmm... From what I've been seeing it is somewhat transparente. Your WSGI
> middleware receives two parameters -- env and a method -- and then process
> it. Inside "env" there would be the information needed to validate the
> username and password. The other parameter would be called "on success" (for
> this case) and would proceed with your application. On failure you could do
> something else.
A little different. There's a simple example here:
http://pythonpaste.org/do-it-yourself-framework.html#wsgi-middleware --
note in this case it is mixing authorization and authentication. Which
is bad of course.
Generally authentication would be implemented once around the entire
application, or very possibly around a suite of applications (forming a
site with a single authentication process). So the middleware would not
really appear as part of the application (though you might want to
implement a simple middleware with the application, for testing and to
make it easy to set up without having to understand all the deployment
options).
I put up a description of a suggested flow in WSGI here:
http://wsgi.org/wsgi/Specifications/simple_authentication
The communication basically takes two forms -- the authenticating
middleware sets REMOTE_USER and optionally some other keys on the way in
(e.g., if you want to pass in a user object, not just a username). If
the user hasn't logged in and needs to, the application responds with
the poorly-named 401 Unauthorized status code. The middleware may
simply annotate that response (e.g., adding WWW-Authenticate) or might
totally rewrite it (e.g., redirecting to a login page).
There are some routines for this in paste.auth, but AuthKit is a more
complete implementation of this idea: http://authkit.org/
This technique works pretty well for complicated login processes like
OpenID, which actually involve a whole series of requests and redirects
(and then ultimately just using a signed cookie).
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
