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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
