www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Mechalas <jo...@ichips.intel.com>
Subject mod_auth-any/1809: Suggestion for improving authentication modules and core source code, problem with 401 and ErrorDocument
Date Mon, 16 Feb 1998 05:31:40 GMT

>Number:         1809
>Category:       mod_auth-any
>Synopsis:       Suggestion for improving authentication modules and core source code,
problem with 401 and ErrorDocument
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Sun Feb 15 21:40:00 PST 1998
>Last-Modified:
>Originator:     johnm@ichips.intel.com
>Organization:
apache
>Release:        All releases, up to 1.3b3
>Environment:
The OS doesn't matter, since the "problem" is with the source code itself.
However, I have built apache on AIX 4.1, Solaris 2.4 and 2.5.1 and SunOS 4.1.3,
and experienced this on all builds.
>Description:
One "problem", or rather, limitation that I have noticed with Apache is the 
interactions of the authentication code in the http_protocol.c code with the
ErrorDocument directive for 401 errors.  If you specify a CGI script as a
handler for 401 errors, Apache sends a blank WWW-Authenticate header, like so:

   WWW-Authenticate:

Instead of the full header:

   WWW-Authenticate: Basic realm="Your realm name here"

This causes the Web browser/client to put up a username/password dialogue box
that reads, 

  "Enter username for unknown at <server>"

instead of,

  "Enter username for <realm name here> at <server>"

This makes it pretty inconvenient to use an ErrorDocument directive to handle
401 errors, since all your protected pages are now, from the browser's point
of view, "nameless".  This can be confusing to the user.

Further, the usefullness of an error handler for 401 requests is severely limited
by the lack of any useful information that the handling CGI script can act upon.
We wanted to implement a 401 handler CGI in order to provide the user with
basic information on why their authentication failed, and what groups they
need to join in order to get access to that page.  This is a very useful thing
in an environment where you have thousands of users hitting your site each
day, running into protected pages...and then some of them filing requests to
get added to the access list...only they don't know what access they need and
you waste a lot of time extracting the information from them.  The problem is,
the CGI script that handles the 401 error gets absolutely no information about
the authentication realm and what access requirements exist.  Short of parsing
the access.conf file (and/or access files in the target directory), there's
no way to know this information...and parsing the access files is not exactly
efficient.
>How-To-Repeat:
Set up an ErrorDocument 401 /to/any/cgi/script

Have the cgi script dump it's environment to stdout...you'll notice there is
no information there regarding the access restrictions of the page you just
tried to access.
>Fix:
We solved both of these problems, the blank WWW-Authenticate header and the
lack of authentication information in the 401 handler, by modifying http_protocol.c and
mod_auth.c (and mod_auth_db.c, though we haven't tested this yet).  The changes
are as follows; I am not claiming that these are the most efficient or the
best ways of addressing the problems, but they work...and I honestly believe
that these kinds of additions to the Apache source would make life easier on
webmasters that want to do what we are doing.

* http_protocol.c

   - Added table_set commands to set environment variables AUTH_NAME and
     AUTH_TYPE.  This allows the 401 error handling CGI to properly generate
     the WWW-Authenticate header by "putting together" the REDIRECT_AUTH_TYPE
     and REDIRECT_AUTH_NAME environment variables that get passed to the 
     subprocess.

* mod_auth*.c

   - Set environment variables via table_set to describe why the authentication
     failed.  AUTH_ERROR is the error message ("user not found", "password
     incorrect" or "permission denied" if they aren't on the ACL for the 
     directory).  AUTH_REQUIRE is set to "user", "group" or "valid-user" as
     per the "require" directive.  AUTH_REQUIRE_ID is the list of users or
     groups that are allowed access to the page, as per the "require" directive.

I have diffs of the distribution source for http_protocol.c, mod_auth.c and
mod_auth_db.c, taken against the modifications that we made to achieve the
above.  There are only a handful of lines of code that need to be added;
http_protocolc gets three new lines.  The auth modules each get about a dozen
new lines.  If you are interested, I can send these to you, or send the full
source.  I have currently modified the 1.2.5 distribution, since that is what
we are running.  I can do the same for 1.3b3 if you wish.

Please consider these additions, or ones with similar effects.
%0
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <apbugs@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]




Mime
View raw message