[Web-SIG] Communicating authenticated user information

[Clark C. Evans]

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:

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

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 have to log Russian user-names and web-pages,
internally I use Unicode strings; and when writing to common log file
format, I simply urlencode the string.  This takes care of spaces and
non-ASCII code points.

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.

On Tue, Jan 24, 2006 at 12:35:48PM -0500, Michal Wallace wrote:
| I think you guys are trying to solve this at the wrong level. 
| This problem should be handled by the web server itself.

People are writing features like this as specific middleware
components so that you don't have a bloated web-server.  

| Maybe I just don't understand why this is important. Can 
| someone (Jim) explain why this is a requirement in the 
| first place?

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.

On Tue, Jan 24, 2006 at 07:31:35AM -0500, Stephan Richter wrote:
| > Why not ``wsgi.context`` or something like that which defaults to
| > an empty dictionary. ?Then you can put what ever you want in it;
| > ``wsgi.user`` just seems to be a bit too specific.
| 
| But if you use a dictionary you need to specify all allowed keys.

Fine, use REMOTE_USER as this is a CGI standard.

| The twisted guys and us have thought about other possible data for
| logging and we could not come up with any. If you have real use cases
| for other data, please let me know.

Depends on the logging level;

0. Trace messages
1. The database instance name used 
2. A sequence of SQL queries executed
3. Files that were created by the request
etc.

I can think of a lot of things I might want to log (and in fact do log);
that said, I'm not interested in this specific application -- I want
the general case spelled-out.  How do I pass information from the
application back to the middleware reliably?

| > Why cannot it just accept a Python string? ?You can always check
| > if it is Unicode or not.
| 
| Because encoding might be arbitrary. It has to be clearly specified in the 
| specs what to expect.

It's very easy for the logging module to check what it has and act
intelligently.   We arn't using C89...

Best,

Clark