[Web-SIG] Communicating authenticated user information

[Phillip J. Eby]

At 01:55 PM 1/24/2006 -0500, Clark C. Evans wrote:
>On Tue, Jan 24, 2006 at 11:33:56AM -0500, Phillip J. Eby wrote:
>| > I think this is way too specific; it doesn't address the general
>| > problem: how do you pass information back up the middleware stack.
>
>| There is no "general problem" which anyone is trying to solve.  The use
>| case requested by Jim and Stephan is quite specific.
>
>Yes there is; it is passing information from applications back to
>middleware (or the server), you even talk about it yourself:

That doesn't mean I admit it's a "general problem".  So far, only this one 
exceedingly obscure use case (whose only merit that I know of so far is 
backward compatibility) has presented a clear and present need for such 
communication at all.


>   | 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
>
>If this is the solution, great.  However, I really don't like the
>``environ`` options out there /w mutable objects.  Can you please
>then specify a *general* mechanism for headers that won't be
>sent to the client?  My server needs to know which ones to strip.

For compatibility reasons, this would have to be a WSGI 1.1 feature.


>On Tue, Jan 24, 2006 at 10:53:53AM -0600, Ian Bicking wrote:
>| Jim Fulton wrote:
>| > Phillip J. Eby wrote:
>| >>I'm pointing out that the use case under consideration isn't specific
>| >>*enough* yet.  Do people's log files support unicode?  Do the
>| >>authentication systems?  This hasn't been made clear, and it should be.
>| >
>| > I agree.  I think we should be guided by the common log file format.
>| > Log data are written to files and are thus not unicode. The user
>| > info is *just* documentation, so it is really up to the app what to
>| > show imo.  Further, because the common log file format is space
>| > delimited, the user info cannot contain spaces.
>|
>| 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.

I agree with it also - but you don't appear to, since you seem to be 
proposing something different in this next paragraph:

>Thus, the WSGI specification should not restrict the character set,
>since some other logging middleware might want to use XML(UTF-8) or
>write each access to a database that is unicode aware.  The value
>should be *any* python string object; let the logging module determine
>the type and encoding and handle it as needed.

+1 for ASCII strings or Unicode objects, but -1 on strings with arbitrary 
encoding.  That's precisely what we *don't* want.


>Well, the general problem is how to communicate information from
>applications back to the middleware or server.  This is one use
>case; there are others, I am sure.

Please feel free to revisit this issue when you have some; in the meantime, 
declaring it a general problem doesn't make it so.  If a pattern emerges 
from the specific solution to multiple specific problems, then it will be 
worth looking at a general solution.  For now, there is only one specific 
problem and generalizing it would be premature, given the exceedingly 
narrow niche of the issue at hand: writing a user name into a server's 
common access log so that existing ZServer users will have backward 
compatibility.

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.