[Web-SIG] Python Web Modules - Version 0.5.0
james at pythonweb.org
Tue Feb 1 00:17:11 CET 2005
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.
More information about the Web-SIG