[Web-SIG] Python Web Modules - Version 0.5.0

[Ian Bicking]

James Gardner wrote:
> Hello All,
> 
> I'd like to announce the release of the Python Web Modules 0.5.0.
> This development release brings WSGI support to the modules.
> 
> * Web Server Gateway Interface support - auth, error, database and session
>   middleware and a WSGI Server.

Cool, good to see more of this kind of stuff.  A couple of notes:

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.

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.

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.

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.

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 -- a piece of middleware for 
indicating error pages would also be nice (similar to Apache's 
ErrorDocument directive).

Since there's a huge number of ways to log someone in, keeping these 
concerns separate seems good.  Apache and Zope are good counterexamples 
where they combined too many aspects of authentication and authorization 
into one bundle.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org