[Web-SIG] Python Web Modules - Version 0.5.0

[James Gardner]

Ian Bicking wrote:

> web.wsgi.error: one standard I'd like for middleware would be some key 
> you could set that would indicate that some error handler exists, and 
> applications further down the stack shouldn't catch unexpected 
> exceptions (of course expected exceptions are a different matter).  
> Then the best error handler available would eventually get the error, 
> and process it somehow (e.g., mailing a report, displaying an error, 
> starting a debugger, etc).  Anyway, something to think about for this.

That could be useful. Presumably the middleware component nearest the 
server is likely to have the best error handling (as you would put the 
best error handler in a position to catch the most errors). So this 
could be as simple as agreeing a variable name like wsgi.error for the 
environ dictionary which the highest middleware component up the chain 
would set to True and ones lower down wouldn't provide error handling if 
it was already set.

Another thing I noticed when writing the error handler is that if an 
application or middleware component doesn't form a header or set the 
status correctly it can be tricky to track down where the error 
occurred. If the application used a special object for headers and 
status in the start_response callable which raised an error when it was 
set with an invalid value that would make life easier.

(Alternatively, if you wanted to change the way things were programmed a 
bit you could write your application as middleware and specify a 
terminator which set the headers and status using these special objects. 
Probably not necessary though!)

> web.wsgi.auth: I've been thinking lot about this as well, particularly 
> about the external interface.  REMOTE_USER seems like a reasonable 
> enough place to put the login information.  I'd like to keep 
> authorization and authentication separate -- one middleware determines 
> who you are, another (might) determine if you are allowed access. 
> Frequently only the application really knows if you are authorized, 
> based on logic that's beyond any ability to make it generic.

Agreed, the underlying API makes this even more explicit than the 
web.wsgi.auth module.. I'll split web.wsgi.auth.Auth into two 
components, one for authentication and one for authorization. The 
existing web.wsgi.auth.Auth will just be a chain of the two components 
and then will have the same functionality.

> So I was thinking that status codes should be sufficient to 
> communicate authorization: 401 for login required, 403 for forbidden.  
> If you are doing cookie logins (which I generally prefer from a UI 
> perspective) the middleware can translate the 401 into a redirect to 
> the login page.  And the 403 can turn into a nicer error page --

So in a new version the authentication middleware would display a sign 
in box if no user was signed in, the authorization middleware would 
provide objects for the application to test authorisation and would also 
look for headers to determine whether the application thought the user 
was authorised and would display a sign in if not.

> a piece of middleware for indicating error pages would also be nice 
> (similar to Apache's ErrorDocument directive).

Agreed, I'll write one.

> web.wsgi.session: I'd like to have some sort of standard for these 
> objects, at least some aspects.  Not the details of storage, but 
> mostly access; along the lines of web.session.manager and/or .store.  
> I'm not sure how I feel about the manager with multiple applications, 
> each of which has a store -- I feel like this should be part of the 
> configuration somehow, which isn't necessarily part of the standard 
> user-visible API.

I've been thinking about the way series of applications can work 
together, which is what the web.wsgi.environment code is about. Perhaps 
it would be better to specify the application name in 
web.wsgi.environment (which is more to do with configuration) so that 
the web.wsgi.session and web.wsgi.auth objects all use the same 
application name and then the manager becomes more redundant because a 
store for the particular application is already created.

> web.wsgi.cgi: is this safe when a piece of middleware changes 
> QUERY_STRING or otherwise rewrites the request?  You can test for this 
> by saving the QUERY_STRING that you originally parsed alongside the 
> resulting FieldStorage, and then reparsing if they don't match.  You 
> can even test for matching with "is", since you're really checking for 
> modifications instead of equality.  The same should be possible for 
> wsgi.input and POST requests.

The web.wsgi.cgi module actually builds the FieldStorage from the 
environ dictionary, not QUERY_STRING so this should mean that middleware 
can do what it likes and the underlying middleware and application will 
respond to the changes.. is this not a good way of doing it?

One other thing I've been meaning to ask.. The WSGI specification 
currently allows no way for an application or middleware components to 
pass custom information back up the middleware chain so that an 
application can ask a middleware component not to perform a certain task 
if it needs to. Communication up the chain can only be provided through 
status, headers, exc_info and content. There could very easily also be a 
response dictionary added as another parameter to start_response, 
similar to environ which sent information up the chain. Was this 
deliberately avoided so that the system wouldn't get complicated?

Thanks again for your comments Ian, much appreciated.

James
--
James Gardner
http://www.pythonweb.org