On Sat, Aug 16, 2014 at 11:29 PM, Graham Dumpleton <grah...@apache.org>
wrote:
> A few comments on this.
>
> The first is that mod_wsgi originally never allowed its
> WSGIPassAuthorization directive in a htaccess file, and then when it it did
> first allow it, it was only honoured if AuthConfig was allowed for that
> context.
>
> I kept having people who needed that ability when they had a htaccess
> file, but didn't have AuthConfig.
>
> One of the things that was pointed out was that if you have htaccess
> enabled, and mod_rewrite was being loaded into Apache, you could get access
> to the Authorization header anyway.
>
> RewriteEngine on
> RewriteBase /
> RewriteCond %{HTTP:Authorization} ^(.*)
> RewriteRule ^(.*)$ $1 [e=HTTP_AUTHORIZATION:%1]
>
> In the end, since mod_wsgi arguably shouldn't ever be used in shared
> environments anyway, I ended up caving in and allowing
> WSGIPathAuthorization in htaccess to make it convenient for the more
> typical scenario that kept coming up.
>
> Now having the ability within mod_wsgi for a web application to handle
> authorisation this showed up a couple of problems in the
> ap_scan_script_header_err_core()
> function. This arose because the response data when it comes back from a
> mod_wsgi daemon process just users the CGI way of doing things and so used
> that function.
>
> The first problem was that when WWW-Authenticate headers came back in a
> response, the ap_scan_script_header_err_core() function would merge the
> values of multiple instances of such headers with a comma in between the
> values. As a result, a single header would get returned back to the HTTP
> client. As with Set-Cookie header, this would cause problems with some HTTP
> clients and they would fail due to the merging. More recent versions of
> mod_wsgi therefore no longer use ap_scan_script_header_err_core() and have
> had to duplicate what it does so as to prevent merging of WWW-Authenticate
> headers.
>
> The second problem was the size limitation on the values of the headers
> coming back from a CGI script. As is, the complete header name and value
> must fit within MAX_STRING_LEN (8192). If the size didn't fit under that,
> you would from memory get the cryptic error message of 'Premature end of
> script header'. In recent times, application such as OpenStack KeyStone
> have been generating values for the WWW-Authenticate header which are
> larger than MAX_STRING_LEN and so they were failing when used with mod_wsgi
> because of the use of ap_scan_script_header_err_core(). In recent versions
> of mod_wsgi, the buffer size used to read the header name and value
> defaults to 8192, but can be overridden through a configuration option to
> allow a larger value to come back.
>
> So irrespective of where you are going to allow this CGIPassHeader
> directive, you might want to look at these other two issues, and if not
> both, certainly the issue of WWW-Authenticate being merged as it will cause
> issues for some browsers if someone ends up passing back multiple
> WWW-Authenticate headers as I am told it can if it supports a choice of
> authentication schemes.
>
> Graham
>
Thanks!
>
>
>
> On 17 August 2014 06:16, Jeff Trawick <traw...@gmail.com> wrote:
>
>> This core directive would be used to modify the processing of
>> ap_add_common_vars() to pass through Authorization or Proxy-Authorization
>> as HTTP_foo. (Nothing else is currently blocked, so any other header name
>> wouldn't make sense.)
>>
>> This directive would be configurable at the directory level, but not in
>> htaccess.
>>
>> Various mods (mod_fastcgi, mod_fcgid, mod_wsgi, etc.) have ways to pass
>> this information through; bug 56855 has a patch to add it to mod_proxy_fcgi
>> too. With that patch in place, at least mod_proxy_scgi in our tree still
>> couldn't front an app that wants to handle Basic auth. It would be good to
>> consolidate over time the code/documentation around suppressing
>> *Authorization.
>>
>> Some concerns: Processing it in ap_add_common_vars() is not finely scoped
>> to natural users of the data; e.g., mod_include and mod_ext_filter would
>> see it. At the same time, not allowing it in htaccess may negate its
>> usefulness in some environments.
>>
>> Thoughts?
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
