It seems to me that authentication and authorization should be a put into a library that isn't bound to the Web at all. I thought that those guys reimplementing J2EE in Python did that. :-/
Oh well, -jj On 7/16/05, Chris McDonough <[EMAIL PROTECTED]> 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. > > 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. > > 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. > > 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. 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. > > > Lately I've been thinking about the role of Paste and WSGI and > > whatnot. Much of what makes a Paste component Pastey is > > configuration; otherwise the bits are just independent pieces of > > middleware, WSGI applications, etc. So, potentially if we can agree > > on configuration, we can start using each other's middleware more > > usefully. > > > > I think we should avoid questions of configuration file syntax for > > now. Lets instead simply consider configuration consumers. A > > standard would consist of: > > > > * A WSGI environment key (e.g., 'webapp01.config') > > * A standard for what goes in that key (e.g., a dictionary object) > > * A reference implementation of the middleware > > * Maybe a non-WSGI-environment way to access the configuration (like > > paste.CONFIG, which is a global object that dispatches to per-request > > configuration objects) -- in practice this is really really useful, as > > you don't have to pass the configuration object around. > > > > There's some other things we have to consider, as configuration syntaxes > > do effect the configuration objects significantly. So, the standard for > > what goes in the key has to take into consideration some possible > > configuration syntaxes. > > > > The obvious starting place is a dictionary-like object. I would suggest > > that the keys should be valid Python identifiers. Not all syntaxes > > require this, but some do. This restriction simply means that > > configuration consumers should try to consume Python identifiers. > > > > There's also a question about name conflicts (two consumers that are > > looking for the same key), and whether nested configuration should be > > preferred, and in what style. > > > > Note that the standard we decide on here doesn't have to be the only way > > the object can be accessed. For instance, you could make your > > configuration available through 'myframework.config', and create a > > compliant wrapper that lives in 'webapp01.config', perhaps even doing > > different kinds of mapping to fix convention differences. > > > > There's also a question about what types of objects we can expect in the > > configuration. Some input styles (e.g., INI and command line) only > > produce strings. I think consumers should treat strings (or maybe a > > special string subclass) specially, performing conversions as necessary > > (e.g., 'yes'->True). > > > > Thoughts? > > > > _______________________________________________ > 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/jjinux%40gmail.com > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. _______________________________________________ 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