[Web-SIG] Communicating authenticated user information
Phillip J. Eby
pje at telecommunity.com
Mon Jan 23 21:02:09 CET 2006
At 02:52 PM 1/23/2006 -0500, Clark C. Evans wrote:
>On Mon, Jan 23, 2006 at 02:25:35PM -0500, Phillip J. Eby wrote:
>| You simply can't use environ values to communicate *up* the WSGI stack,
>| since at no level is it guaranteed you have the "same"
>The same could be said for response headers, no? You've got a WSGI
>stack of A, B, and C. Just beacuse "C" sets a header intended for A,
>doesn't mean that B has to pass it on.
That's a feature, not a bug. However, the presumption is that middleware
will in general pass through the same *set* of environ variables or
response headers as it received, unless it has a reason to modify
them. This does not require middleware to pass the same 'environ' or
'header' *objects*, just that in general they should pass through the
>| In the case of authentication, it should be sufficient to have a
>| callable or mutable in the environ that can be called or set more than
>| once per request, i.e. it only takes effect once the request is
>| completed. This allows outer middleware to override what inner
>| middleware or the application set it to.
>This is exactly what environ['REMOTE_USER'] is, a mutable value in
>the environ that can be set more than once,
Strings aren't mutable.
>and only the current
>value matters when create_response hits the request log middleware.
The current value in *which* environ? The application doesn't necessarily
have the same environ object as the server, so modifying it will make no
difference to anything.
>| Response headers and callables (or mutables) in the environ
>| are the only way to send stuff upstream. You also have to be careful
>| that any upstream communication doesn't bypass something that middleware
>| should be allowed to control.
>Of course you have to be careful and work out a protocol that all
>intermediate middleware components agree upon. However, beyond that
>I fail to understand the distinctions you're making or why they
>are important. Perhaps a tangable example would help to educate me?
Middleware is not required to pass the same environ to a child application
that it received from its parent server, and environ objects are not
returned to the caller. Ergo, modifying 'environ' itself (as opposed to
modifying an object *in* the environment), cannot guarantee that the server
will "see" the change unless middleware specifically conspires to make this
so. This is the opposite of the way it should work, which is that it
should be communicated to the server unless the middleware specifically
conspires to prevent it (e.g. by stripping the environ entry that allows
the communication, or by changing the value before returning).
More information about the Web-SIG