Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Clark C. Evans
On Wed, Jan 25, 2006 at 12:41:01AM -0500, Michal Wallace wrote: | Unfortunately, if you require it to be the exact same | *object* then you're making the requirement that | everything in the stack happens in the same process, | on the same machine. Correct. Phillip's extension APIs approach h

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Michal Wallace
On Tue, 24 Jan 2006, Clark C. Evans wrote: > 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

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Phillip J. Eby
At 09:42 PM 1/24/2006 -0500, Clark C. Evans wrote: >Nice sermon; now can we get back to the issue being discussed without >being argumentative and santimonious? I didn't notice anyone being either of those. As for the sermon, however, I'm glad you enjoyed it. :) >Another use case for passing

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread 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",

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Michal Wallace
On Tue, 24 Jan 2006, Jim Fulton wrote: > Michal Wallace wrote: > > > Maybe I just don't understand why this is important. Can someone (Jim) > > explain why this > > is a requirement in the first place? > > We do our own authentication for lots of reasons, including: ... > History has shown us th

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Jim Fulton
Michal Wallace wrote: > On Tue, 24 Jan 2006, Jim Fulton wrote: > ... > Maybe I just don't understand why this is > important. Can someone (Jim) explain why this > is a requirement in the first place? We do our own authentication for lots of reasons, including: - Zope can provide user and group

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread 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

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Phillip J. Eby
At 12:35 PM 1/24/2006 -0500, Michal Wallace wrote: >Maybe I just don't understand why this is >important. Can someone (Jim) explain why this >is a requirement in the first place? I'd like to know too, although the obvious argument is backward compatibility for people accustomed to ZServer as Zope

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Herb Lainchbury
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 wan

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread 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

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Michal Wallace
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

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Ian Bicking
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

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Phillip J. Eby
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

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Jim Fulton
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

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Phillip J. Eby
At 10:15 PM 1/23/2006 -0500, Clark C. Evans wrote: >On Mon, Jan 23, 2006 at 04:15:06PM -0500, Phillip J. Eby wrote: >| At 03:36 PM 1/23/2006 -0500, Stephan Richter wrote: >| > Specify a new environment variable called 'wsgi.user' (or something >| > similar) that is a mutable and can be written seve

Re: [Web-SIG] Communicating authenticated user information

2006-01-24 Thread Stephan Richter
On Monday 23 January 2006 22:15, Clark C. Evans wrote: > On Mon, Jan 23, 2006 at 04:15:06PM -0500, Phillip J. Eby wrote: > | At 03:36 PM 1/23/2006 -0500, Stephan Richter wrote: > | > Specify a new environment variable called 'wsgi.user' (or something > | > similar) that is a mutable and can be writ