On 3/5/06, Ben Bangert <[EMAIL PROTECTED]> wrote:
> There's several things that lose features if moved purely to
> middleware, like Auth functions, where you might want to do,
> Auth.user_can(permission='edit_people'), even though the environ might
> not contain anything having to do with users or permissions. So while
> WSGI sounds great, and it is, for a lot of things, it definitely has
> its place, and library functions work great for a lot of this as well.
Authentication in middleware is relatively easy. "If user is not
logged in, divert to login page, then take him back where he was."
The middleware can block access to a page or section, or set "hints"
in the environment (essentially an Auth object of some sort). But
ultimately some kinds of authorization will be tied too closely to the
application logic to be feasable with middleware.
> > What also will begin to happen (or at least should happen) is that
> > we'll start using the environ dict in a more expanded fashion. I'm
> > thinking of something akin to Zope3's Interfaces, but not so formal.
> > So, "Identity" middleware will set a "wsgi.Identity" which will contain
> > UserName, Groups, Roles, Permissions, etc. Then, a Authorization
> > check is completely separate from the Identity mechinism. I suspect
> > we'll need something like PEPs just for this (it will have to move far
> > faster than PEPs do - especially initially). Vision: a TurboGears
> > application should run under Zope that has a wsgi interface and may
> > even be able to handle simple permissions.
>
> But why? Why cloud up environ needlessly? A thread-local global with a
> library that any app can use up and down the chain accomplishes the
> same thing, without clouding up environ.
Mainly to standardize the ways in which frameworks and libraries
interact. A robust generic auth library could replace an auth
middleware, but would we get into an "every library does things
differently" situation? Would different auth implementations have a
compatible API so you can switch between them? Would the auth library
be consistent with your other libraries? Why is it so bad to have the
Auth object in the WSGI enviroment; it has to be somewhere.
> > 1) How to communicate upstream? For instance, if I want to logout, I
> > need to let the Identity middleware know that. Can I set something
> > magic in environ? Do I have to throw an exception?
> > 3) The wsgi standard says that no inspection of wsgi applications is
> > allowed.
What does that mean? That the application can't set an environ flag
("logout") to signal the middleware? If so, that sounds like a bug in
the spec, which a use case like this would expose. The application
may want to handle the logout page/redirect, or it may want to let the
middleware to, but in any case the middleware may have to do some
behind-the-scenes cleanup. Having an exception means the exception
handler gets to choose what the logout page looks like, and if the
exception handler comes from still a third package, that becomes
problematic.
> Finally, if each controller is a wsgi app, does that mean it has to
> setup the thread-local globals again for the current application? I
> think my main issue with making each controller a wsgi app, is that it
> really isn't. If you consider a WSGI app to be a stand-alone
> application (which I think it should be), then it doesn't make sense.
> Controllers depend on other controllers being where they are, because
> controllers are all part of a single application. WSGI apps don't care
> about anything outside of them-self.
That is a bit of a tension. Quixote normally considers the publisher
+ root directory as persistent objects that last the lifetime of the
server. But WSGI'ifying it creates separate instances for each
request. It doesn't seem to break things in practice because the
overhead is insignificant, the module globals persist (for shared data
that's not tied to a request or session), and the application has to
be multiprocess-safe anyway, but it does mean you're (mis)using the
framework in a way that wasn't intended.
> Does each controller have to parse environ, and setup a request object
> again? There's a lot of setup stuff a framework does when it starts
> handling a WSGI call, is that all going to be pushed into each
> controller?
In Quixote's WSGIServer (I don't remember the download location
offhand), the WSGI interface creates a Request object and calls the
Publisher's usual entry point, so the controller doesn't have to do
anything unusual. WSGIServer is at the same level as the other
servers (SCGIServer, SimpleServer, etc.)
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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
-~----------~----~----~----~------~----~------~--~---
