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
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/
>
>
