[Web-SIG] Communicating authenticated user information

[Phillip J. Eby]

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"
>| dictionary.
>
>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 
*contents*.


>| 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).