Phillip J. Eby ha scritto:
At 11:21 PM 7/7/2008 +0200, Manlio Perillo wrote:
So this is not a "bad" middleware, IMHO.
True, but it's part of the application, rather than being transparent.
Ok, I agree.
Does this means that such non trasparent middlewares must not be
inserted inside the "gateway middleware stack", even if this is done
only as a convenience (so that you don't have to use a decorator for
every functions)?
By the way, a middleware that is responsible for user authentication:
http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/auth/http_middleware.py
is a good middleware?
To keep it simple, the middleware check if there is an authorization
header and the credentials are correct.
If this is true, execute the WSGI application (setting
environ['REMOTE_USER']), otherwise return a forbidden response.
Right - that's transparent middleware: the application doesn't need to
know it's there.
I think that it's rather subtle.
If you remove the middleware, the application is no more able to handle
authenticated user.
This is not a problem, the application is still able to work correctly,
but the same applies to my messages middleware, IMHO.
Under WSGI 2.0, it's even easier since you don't need decorators to
manipulate your response: you can just "return someapi(...)" where
the "..." is whatever you were going to return directly.
return someapi() from inside the WSGI application?
Yes.
Do you have a working example?
Also, can you post an example of a middleware that needs to replace the
environ dictionary?
Thanks Manlio Perillo
_______________________________________________
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
