[Web-SIG] Communicating authenticated user information
Clark C. Evans
cce at clarkevans.com
Tue Jan 24 19:55:34 CET 2006
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
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...
More information about the Web-SIG