Hi,
only short notes from me. I'd appreciate such a directive very much. I
think, allowing it in .htaccess won't hurt. I can't come up with a use
case, where the person behind the script doesn't have access to the
credentials anyway.
As for the passing right now, you don't need the whole mod_rewrite machinery
for this:
SetEnvIf Authorization (.+) HTTP_AUTHORIZATION=$1
that's, what I've been using so far :)
nd
* Graham Dumpleton 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
>
> On 17 August 2014 06:16, Jeff Trawick <[email protected]> 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/
--
>kann mir jemand sagen, was genau @-Domains sind?
Ein Mythos. Ein Werbetrick. Verarsche. Nenn es wie du willst...
-- Alexandra Buss und Björn Höhrmann in dciwam
