[Web-SIG] Communicating authenticated user information

[Clark C. Evans]

On Tue, Jan 24, 2006 at 05:34:19PM -0500, Phillip J. Eby wrote:
| By turning that narrowly-stated issue into a general problem, you're 
| dissolving three dimensions of specificity at once: i.e., you're turning 
| the problem into essentially "communicating something about anything to 
| anybody", which no longer carries any useful information for making 
| design tradeoffs, especially since you are not presenting any 
| alternative use cases that present examples with different values along 
| any of the generalized dimensions.  This is unsound design practice, and 
| it simply leads to people jabbering misunderstandings at each other 
| while they think they're communicating.  Let's stick to real-life use 
| cases, please, not theoretical ones.  In the meantime, extension APIs as 
| provided for by the existing PEP present an adequate ad hoc "upstream" 
| communications facility.

Nice sermon; now can we get back to the issue being discussed without
being argumentative and santimonious?

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.

However, this implementation violates your vision of WSGI, since I am
assuming that the later stacks will pass along the current environment:

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

The problem with "fixing" my implementation with this approach is
that it unnecessarly couples cookie and digest modules.  I don't
think it is necessary nor a good idea to have decoupled modules
dependent on each other via a callable in the ``environ``.
So, I reject this approach, and I suggested that the same ``environ`` 
object should be passed all the way down the WSGI stack.

    On Tue, Jan 24, 2006 at 11:41:04AM -0500, Phillip J. Eby wrote:
    | At 10:30 PM 1/23/2006 -0500, Clark C. Evans wrote:
    | >Suggested Wording:
    | >
    | >   A WSGI Middleware component (that is, one that receives a
    | >   request and forwards it on to another component) must forward
    | >   on the *exact* same ``environ`` dict that it received.
    | 
    | -1.  This invalidates current WSGI design principles and can't
    | go in any WSGI 1.x version, and even for a WSGI 2.x it would 
    | need a heck of a lot more justification.

Having the *same* ``environ`` passed all the way up the stack works --
nicely.  I've not yet seen a rationale why WSGI should not have this
limitation; 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.

    On Tue, Jan 24, 2006 at 11:41:04AM -0500, Phillip J. Eby wrote:
    | Note that WSGI is an HTTP analogue, it is not a web server
    | API.  In the context of this discussion, I'm now more
    | convinced than ever that the right place to communicate
    | information back to the server is via response headers,
    | and that's how this use case should be addressed in WSGI
    | 1.1, as it maintains the functional composition of
    | middleware better than an environ-supplied extension.  In
    | WSGI the design principle needs to be "Isolation beats
    | cleanliness".

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.

On Tue, Jan 24, 2006 at 05:34:19PM -0500, Phillip J. Eby wrote:
| >On Tue, Jan 24, 2006 at 10:53:53AM -0600, Ian Bicking wrote:
| >| It is up to the consumer to handle any unicode, and to maintain the
| >| integrity of their log format regardless of input.
| >
| >I second Ian's opinion.
| 
| +1 for ASCII strings or Unicode objects

Perfect.


Kind Regards,

Clark