The problem is sys admins who don't know what they are doing as far as
administering Apache.
I used to work in a corporate environment where they allowed everyone a
~username directory for placing stuff. As they wanted to allow people to
setup certain type of scripts in their directory, they allowed .htaccess
files.
Only thing wrong with that is that they also required you to authenticate
using HTTP basic authentication with your own credentials to access anyones
~username directory.
Using any of the backdoors you could harvest credentials by getting others
in the company to go to your personal ~username area.
So in some respects if a directive is going to be provided, it has to be
something that can be consulted by any module and all core modules which
have such backdoor ways of getting at the authorisation header should be
changed to block access if the directive hasn't been set to allow access to
that header.
If this was possible then I would certainly change mod_wsgi to be gated by
the directive as an extra step as I can't say that I am happy that I
allowed myself to be pushed into allowing enabling in .htaccess files with
the mod_wsgi option.
Graham
On 19 August 2014 06:29, André Malo <n...@perlig.de> wrote:
> 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 <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/
>
>
>
> --
> >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
>
