Chris McDonough wrote: > I've also been putting a bit of thought into middleware configuration, > although maybe in a different direction. I'm not too concerned yet > about being able to introspect the configuration of an individual > component. Maybe that's because I haven't thought about the problem > enough to be concerned about it. In the meantime, though, I *am* > concerned about being able to configure a middleware "pipeline" easily > and have it work.
There's nothing in WSGI to facilitate introspection. Sometimes that seems annoying, though I suspect lots of headaches are removed because of it, and I haven't found it to be a stopper yet. The issue I'm interested in is just how to deliver configuration to middleware. Because middleware can't be introspected (generally), this makes things like configuration schemas very hard to implement. It all needs to be late-bound. > I've been attempting to divine a declarative way to configure a pipeline > of WSGI middleware components. This is simple enough through code, > except that at least in terms of how I'm attempting to factor my > middleware, some components in the pipeline may have dependencies on > other pipeline components. At least in Paste, you just have to set up the stack properly. It would be cool if middleware could detect the presence of its prerequesites, and add the prerequesites if they weren't present; I don't think that's terribly complicated, but I haven't actually tried it. Mostly you'd test for a key, and if not present then you'd instantiate the middleware and reinvoke. > For example, it would be useful in some circumstances to create separate > WSGI components for user identification and user authorization. The > process of identification -- obtaining user credentials from a request > -- and user authorization -- ensuring that the user is who he says he > is by comparing the credentials against a data source -- are really > pretty much distinct operations. There might also be a "challenge" > component which forces a login dialog. I've always thought that a 401 response is a good way of indicating that, but not everyone agrees. (The idea being that the middleware catches the 401 and possibly translates it into a redirect or something.) > In practice, I don't know if this is a truly useful separation of > concerns that need to be implemented in terms of separate components in > the middleware pipeline (I see that paste.login conflates them), it's > just an example. Do you mean identification and authentication (you mention authorization above)? I think authorization is different, and is conflated in paste.login, but I don't have any many use cases where it's a useful distinction. I guess there's a number of ways of getting a username and password; and to some degree the authenticator object works at that level of abstraction. And there's a couple other ways of authenticating a user as well (public keys, IP address, etc). I've generally used a "user manager" object for this kind of abstraction, with subclassing for different kinds of generality (e.g., the basic abstract class makes username/password logins simple, but a subclass can override that and authenticate based on anything in the request). Maybe there's a better term, the fact these two words start with "auth" causes all kinds of confusion. Conflating identification and authentication isn't so bad, but authentication and authorization is really bad (but common). > But at very least it would keep each component simpler > if the concerns were factored out into separate pieces. > > But in the example I present, the "authentication" component depends > entirely on the result of the "identification" component. It would be > simple enough to glom them together by using a distinct environment key > for the identification component results and have the authentication > component look for that key later in the middleware result chain, but > then it feels like you might as well have written the whole process > within one middleware component because the coupling is pretty strong. > > I have a feeling that adapters fit in here somewhere, but I haven't > really puzzled that out yet. I'm sure this has been discussed somewhere > in the lifetime of WSGI but I can't find much in this list's archives. No, I don't think so. It was something I experimented with in paste.login (purely intellectually, I haven't used it in a real app), and Aaron Lav did a little work on it as well, but until it gets some use it's hard to know how complete it is. As long as it's properly partitioned, I don't think it's a terribly hard problem. That is, with proper partitioning the pieces can be recombined, even if the implementations aren't general enough for all cases. Apache and Zope 2 authentication being examples where the partitioning was done improperly. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com