Is password leaking enabled by default?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. In a webpy application request handler, write 

web.debug.write('REMOTE_USER "%s"\n" % 
        web.ctx.environ.get("REMOTE_USER", "")
    )

2. Configure .htaccess to require valid user. Don't declare the
WSGIPassAuthorization directive.
3. Observe user name in Apache 2.2.4 error log.

What is the expected output? What do you see instead?

I thought that HTTP_AUTHORIZATION will be passed to webpy's web.wsgiserver.

What version of the product are you using? On what operating system?

Subversion checkout, revision 555 (2007-09-23).

Please provide any additional information below.

webpy 0.210-1 in Ubuntu gutsy

Original issue reported on code.google.com by eelgh...@gmail.com on 6 Nov 2007 at 1:10

[GoogleCodeExporter]

I thought that HTTP_AUTHORIZATION would be passed to webpy's web.wsgiserver 
only when
WSGIPassAuthorization is On.  If I read mod_wsgi.c correctly, the flag's default
value -1 is considered as "enabled" by the "if" statement, contrary to the 
comment
preceding it.

Original comment by eelgh...@gmail.com on 6 Nov 2007 at 1:12

[GoogleCodeExporter]

Err, revision 557 (2007-09-26).

Original comment by eelgh...@gmail.com on 6 Nov 2007 at 1:17

[GoogleCodeExporter]

Which 'if' check. There are two parts. When constructing configuration object 
do:

    config->pass_authorization = dconfig->pass_authorization;

    if (config->pass_authorization < 0) {
        config->pass_authorization = sconfig->pass_authorization;
        if (config->pass_authorization < 0)
            config->pass_authorization = 0;
    }

Then later:

    if (config->pass_authorization) {
        value = apr_table_get(r->headers_in, "Authorization");
        if (value)
            apr_table_setn(r->subprocess_env, "HTTP_AUTHORIZATION", value);
    }

Thus, if unset, ie., -1, when creating configuration object then should be 
forced to
be 0, ie. boolean false. Thus later check should fail and it shouldn't be 
passed.

I'll check actual behaviour again, but pretty sure it was okay last time I 
checked.

Original comment by Graham.Dumpleton@gmail.com on 6 Nov 2007 at 1:18

[GoogleCodeExporter]

Today's checkout of modwsgi (revision 644) still exposes HTTP_AUTHORIZATION by 
default.

Original comment by eelgh...@gmail.com on 6 Nov 2007 at 1:22

[GoogleCodeExporter]

I was looking at the second snippet when I thought that -1 is "enabled".  Since 
you
pointed me to another piece of code above it, I am not sure if my judgment is
correct.  The only thing I know for sure is that webpy's REMOTE_USER is 
determined
without the WSGIPassAuthorization directive.  And I grepped Apache's global
configuration for that directive too.

Original comment by eelgh...@gmail.com on 6 Nov 2007 at 1:29

[GoogleCodeExporter]

The REMOTE_USER variable is always passed. What isn't being passed by default 
is the
HTTP Authorization header, as HTTP_AUTHORIZATION, since it is what contains the
password. It is still useful to know who the user is and is harmless to pass it 
when
Apache is doing the authentication. This is inline with what CGI scripts do, 
although
in CGI there is no way to pass HTTP_AUTHORIZATION onto the actual script as 
mod_wsgi
optionally allows.

Original comment by Graham.Dumpleton@gmail.com on 6 Nov 2007 at 1:38

[GoogleCodeExporter]

My apologies for a false alarm.

REMOTE_USER is just what I needed.  Great!

Original comment by eelgh...@gmail.com on 6 Nov 2007 at 2:01

[GoogleCodeExporter]

Closing. Don't believe documentation needs to be enhanced as issue is covered in
documentation on configuration directives as well as in documentation convering
configuration guidelines.

Original comment by Graham.Dumpleton@gmail.com on 6 Nov 2007 at 2:06

• Changed state: Invalid
• Added labels: Type-Other
• Removed labels: Type-Defect