It seems to me that applications should be concerned only about what applications need to be concerned about. If an application happens to be a login screen for a system, then that application will be concerned with setting the userid somewhere.
The fact that the middleware or the webserver wants to log that information somewhere is none of the applications business. The middleware is providing the service to the application so the middleware gets to define the interface for those services. One of those services is the userid. Most applications will just want to know the userid and can get it by accessing wsgi.userid. Applications that need to modify the userid (like login & logout applications) can do so by setting wsgi.userid. For example: if the login application decides that a user has entered sufficient credentials to satisfy the authentication criteria then it just sets the wsgi.userid attribute and it's done. Now, if the middleware wants to do something with that value (like log it), great, but the application doesn't need to know that and need not be concerned with it. There may be other values that applications can set but userid is one that many applications will need and I prefer the specific member for this purpose. BTW, if authentication is being done with HTTP then there's no need for the login and logout applications and the middleware still has the responsibility of providing the userid attribute for applications. The middleware set that attribute based on the HTTP information available. Herb Lainchbury Dynamic Solutions Inc. www.dynamic-solutions.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michal Wallace Sent: Tuesday, January 24, 2006 9:36 AM To: Jim Fulton Cc: web-sig@python.org Subject: Re: [Web-SIG] Communicating authenticated user information On Tue, 24 Jan 2006, 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. I'm curious. Suppose that a subset of your site or application requires users to log in through an HTML form, but that for some reason there's also a general HTTP authentication username and password over the whole system. Which username should the web server log? I think you guys are trying to solve this at the wrong level. This problem should be handled by the web server itself. Even if you want to use your own custom forms, there is already a really nice solution to this problem for apache: http://aspn.activestate.com/ASPN/CodeDoc/Apache-AuthCookie/AuthCookie.html If a particular webserver doesn't allow this sort of approach, then maybe the work should be done there? Meanwhile, you can always do your own logging for the events you actually want to record at the application layer. Maybe I just don't understand why this is important. Can someone (Jim) explain why this is a requirement in the first place? Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ ------------------------------------- _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/herb%40dynamic-solutions.com _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
