[Web-SIG] Communicating authenticated user information

[Phillip J. Eby]

At 09:42 PM 1/24/2006 -0500, Clark C. Evans wrote:
>Nice sermon; now can we get back to the issue being discussed without
>being argumentative and santimonious?

I didn't notice anyone being either of those.  As for the sermon, however, 
I'm glad you enjoyed it.  :)


>Another use case for passing information "up" the WSGI stack is is where
>you have two 'othogonal' but decoupled modules, each of which have a
>role/interface that could be implemented by an equivalent replacement:
>
>   'paste.auth.digest'
>      This does authentication handling, sending a 401 back to
>      the server if REMOTE_USER is not already filled in.
>
>   'paste.auth.cookie'
>      This looks for a cookie and injects REMOTE_USER into the
>      environ on the way "down"; it then looks for a REMOTE_USER
>      to save via a cookie on the way "up".  It is a simple and
>      elegant mechanism.

I don't see why an extension API placed in the environ, such as 
"paste.auth.set_user" doesn't satisfy this use case.


>The problem with "fixing" my implementation with this approach is
>that it unnecessarly couples cookie and digest modules.

You lost me.  How does it do that in any way that the 'REMOTE_USER' 
variable does not?


>So, I reject this approach, and I suggested that the same ``environ``
>object should be passed all the way down the WSGI stack.

And as I've already said, this simply isn't possible in WSGI 1.x, as it's 
not backward compatible.  That needs to be a 2.x revision, if it happens at 
all.


>Having the *same* ``environ`` passed all the way up the stack works --
>nicely.

So do extension APIs.


>   I've not yet seen a rationale why WSGI should not have this
>limitation;

Because WSGI is designed for functional composability.  Requiring environ 
passthrough breaks that by creating a global coupling.  If anything, in a 
2.x WSGI version I would lean towards getting rid of extension APIs and 
replacing them with some kind of additional response facility, as it's 
still too easy to create global coupling or to bypass middleware via 
extension APIs.


>Ian presented 2 use cases in paste where a different environ
>is passed down the stack, however, both of his cases can be fixed (as I
>demonstrated) to be compliant with the suggested wording above.

So we can make it harder for people to write middleware, in order to make 
it easier for people to introduce global coupling?  That doesn't sound like 
a useful tradeoff -- certainly not one that overcomes the cost of changing 
the spec.


>Well, regardless of what you intended of WSGI, it is a web server API;
>and a particularly good low-level one.  The current usage I have of
>using the ``environ`` to pass information *up* does provide a great deal
>of isolation, and the solutions so far don't have the same advantages.

Not so.  It's just as easy to create a 'paste.remote_user' environ key that 
contains a 1-element list with a value in it, if you insist on having 
global coupling.  That works today with the existing spec and likely always 
will, is trivial to implement, and requires no "fixing" of existing 
middleware that isn't broken.