Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
On Tuesday 07 February 2006 12:28, Phillip J. Eby wrote: > * Add an optional 'wsgi.response_filtering' key to the spec. If its value > is present and true, the server promises to prevent 'X-Internal-*' headers > from being transmitted. > > * Add an optional 'X-Internal-WSGI-Authenticated-User' header to the spec, > that indicates the authenticated user name. This should only be inserted > into the response headers if 'wsgi.response_filtering' is in effect. > > * Require that any user-defined X-Internal headers include a product name, > e.g. 'X-Internal-Zope-Foo', to avoid conflict with WSGI-defined or other > products' user-defined headers. > > This would all be placed under a new section entitled "Internal Response > Headers" and defined as an optional extension. > > Any thoughts? This sounds really good! Thanks for the great summary and suggestions. As far as I can tell it solves all of our use cases and addresses our security concerns; i.e. not sending the username to the client. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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
Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
Phillip J. Eby wrote: > So, if there are no objections, I propose that we: > > * Add an optional 'wsgi.response_filtering' key to the spec. If its value > is present and true, the server promises to prevent 'X-Internal-*' headers > from being transmitted. > > * Add an optional 'X-Internal-WSGI-Authenticated-User' header to the spec, > that indicates the authenticated user name. This should only be inserted > into the response headers if 'wsgi.response_filtering' is in effect. > > * Require that any user-defined X-Internal headers include a product name, > e.g. 'X-Internal-Zope-Foo', to avoid conflict with WSGI-defined or other > products' user-defined headers. > > This would all be placed under a new section entitled "Internal Response > Headers" and defined as an optional extension. > > Any thoughts? Sounds good to me, and wsgi.response_filtering seems to address the backward compatibility well. It would be easy, for instance, to apply the filtering in the logging middleware if the server was not already filtering the response, and set the key to represent that the filtering was in place. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ 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
Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
At 11:50 AM 2/7/2006 -0600, Ian Bicking wrote: >Phillip J. Eby wrote: >>So, if there are no objections, I propose that we: >>* Add an optional 'wsgi.response_filtering' key to the spec. If its >>value is present and true, the server promises to prevent 'X-Internal-*' >>headers from being transmitted. >>* Add an optional 'X-Internal-WSGI-Authenticated-User' header to the >>spec, that indicates the authenticated user name. This should only be >>inserted into the response headers if 'wsgi.response_filtering' is in effect. >>* Require that any user-defined X-Internal headers include a product >>name, e.g. 'X-Internal-Zope-Foo', to avoid conflict with WSGI-defined or >>other products' user-defined headers. >>This would all be placed under a new section entitled "Internal Response >>Headers" and defined as an optional extension. >>Any thoughts? > >Sounds good to me, and wsgi.response_filtering seems to address the >backward compatibility well. It would be easy, for instance, to apply the >filtering in the logging middleware if the server was not already >filtering the response, and set the key to represent that the filtering >was in place. This brings up an interesting point, which is to what extent middleware can or should filter internal headers it doesn't understand, and what kinds of functionality are acceptable to expose via response headers. That issue deserves some more thought before the spec addition is made, although for this particular application I'm thinking that folks are probably safe prototyping based on just the info above. The only issue remaining is whether there are any objecting parties. I believe that Clark Evans eventually agreed that response headers were the best long-term way to address middleware composition issues in upward communication like this, but we should leave the proposed extension open to objections for a few days in any case. And of course the issue of what's acceptable to expose via headers and what's acceptable for middleware to ignore or pass through is very much open for discussion, since it needs to be resolved before the actual spec can be written. ___ 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
Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
On Feb 7, 2006, at 12:28 PM, Phillip J. Eby wrote: > * Add an optional 'wsgi.response_filtering' key to the spec. If > its value > is present and true, the server promises to prevent 'X-Internal-*' > headers > from being transmitted. > > * Add an optional 'X-Internal-WSGI-Authenticated-User' header to > the spec, > that indicates the authenticated user name. This should only be > inserted > into the response headers if 'wsgi.response_filtering' is in effect. > > * Require that any user-defined X-Internal headers include a > product name, > e.g. 'X-Internal-Zope-Foo', to avoid conflict with WSGI-defined or > other > products' user-defined headers. > > This would all be placed under a new section entitled "Internal > Response > Headers" and defined as an optional extension. I like it. James ___ 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
Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
Phillip, You are correct, I'm convinced that response headers are the place to include this sort of inter-middleware communication. On Tue, Feb 07, 2006 at 12:28:09PM -0500, Phillip J. Eby wrote: | * Add an optional 'wsgi.response_filtering' key to the spec. If its value | is present and true, the server promises to prevent 'X-Internal-*' headers | from being transmitted. I absolutely love wsgi.response_filtering, only I feel that it should be a *mutable* listing of the headers that the server should strip. If the list is not present, then response filtering is not available. In particular, I think that requring 'X-Internal-' is not quite explicit enough and, at the same time, too limiting. | * Add an optional 'X-Internal-WSGI-Authenticated-User' header to the spec, | that indicates the authenticated user name. This should only be inserted | into the response headers if 'wsgi.response_filtering' is in effect. | | * Require that any user-defined X-Internal headers include a product name, | e.g. 'X-Internal-Zope-Foo', to avoid conflict with WSGI-defined or other | products' user-defined headers. | | This would all be placed under a new section entitled "Internal Response | Headers" and defined as an optional extension. Sure; these are good suggestions. Best, Clark ___ 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
Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
At 08:22 PM 2/7/2006 -0500, Clark C. Evans wrote: >I absolutely love wsgi.response_filtering, only I feel that it should be >a *mutable* listing of the headers that the server should strip. If >the list is not present, then response filtering is not available. In >particular, I think that requring 'X-Internal-' is not quite explicit >enough and, at the same time, too limiting. I don't understand what you want to do with this. Can you be more specific about what's limiting and how, not to mention what you expect to do with this mutable list? Thanks. ___ 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
Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
On Tue, Feb 07, 2006 at 09:20:38PM -0500, Phillip J. Eby wrote: | At 08:22 PM 2/7/2006 -0500, Clark C. Evans wrote: | >I absolutely love wsgi.response_filtering, only I feel that it should be | >a *mutable* listing of the headers that the server should strip. If | >the list is not present, then response filtering is not available. In | >particular, I think that requring 'X-Internal-' is not quite explicit | >enough and, at the same time, too limiting. | | I don't understand what you want to do with this. Can you be more | specific about what's limiting and how, not to mention what you expect | to do with this mutable list? Thanks. | I think it is unnecessarly limiting since you might want the server to filter (not send to the client) other headers, such as something like the Meter header defined in RFC 2227. This seems like a generally useful feature; I don't see the need to restrict it to only headers starting with 'X-Internal-'. At the same time, explicitly listing the headers you wish to filter isn't that much of a burden -- and actually helps document (paste.lint could, for example, issue warnings of all 'X-Internal-' headers that arn't listed for filtering; this could be used to catch spelling errors). Kind Regards, Clark ___ 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
Re: [Web-SIG] Logging the authenticated user (was Re: Bowing out)
At 10:47 AM 2/8/2006 -0500, Clark C. Evans wrote: >On Tue, Feb 07, 2006 at 09:20:38PM -0500, Phillip J. Eby wrote: >| At 08:22 PM 2/7/2006 -0500, Clark C. Evans wrote: >| >I absolutely love wsgi.response_filtering, only I feel that it should be >| >a *mutable* listing of the headers that the server should strip. If >| >the list is not present, then response filtering is not available. In >| >particular, I think that requring 'X-Internal-' is not quite explicit >| >enough and, at the same time, too limiting. >| >| I don't understand what you want to do with this. Can you be more >| specific about what's limiting and how, not to mention what you expect >| to do with this mutable list? Thanks. >| > >I think it is unnecessarly limiting since you might want the server to >filter (not send to the client) other headers, such as something like >the Meter header defined in RFC 2227. This seems like a generally >useful feature; I don't see the need to restrict it to only headers >starting with 'X-Internal-'. > >At the same time, explicitly listing the headers you wish to filter >isn't that much of a burden -- and actually helps document (paste.lint >could, for example, issue warnings of all 'X-Internal-' headers that >arn't listed for filtering; this could be used to catch spelling errors). My concerns about this are that it introduces unnecessary coupling and doesn't reflect the intended use case, which is for allowing internal communication between WSGI servers and applications. These are all internal headers, and I don't see how or why 'Meter' would be used with this. It also seems to me that the spellcheck use case would be better handled by defining a 'wsgi.known_internal_headers' provided by the server to the application, so that the application can determine whether a particular piece of functionality is supported. In other words, I still don't see the purpose of having a mutable; the environ key is for the server to communicate to the app, not the other way around. (Which is done by the headers themselves.) ___ 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
