It would be possible to implement optional HTTP Authentication (something that people seem to want often enough; see links below) without violating any RFCs. Optional Auth Process --------------------- The idea is that (if the feature were turned on) the process would work as follows: 1. A request comes in from a web browser for a page marked with optional authentication 2. Seeing no authentication, Apache passes this on to the CGI/mod_perl that will process it 3. The CGI/mod_perl sends back a response with a 401/WWW-Authenticate 4. Apache, seeing authentication in the response this time, processes the authentication. Either way, it passes control back to the CGI/mod_perl, but if the authentication failed, it will not populate the variables containing the username and the like. It is up to the CGI/mod_perl how to respond to this. Changes required ---------------- The change required in Apache to achieve this is fairly simple: if optional auth is specified (eg. in a .htaccess), pass control to the CGI/mod_perl even if the auth fails; don't respond with a 401 or a WWW-Authenticate. Suggested config syntax: AuthOptional On Presumably, this should also be part of AllowOverride AuthConfig Additional Information ---------------------- I'm not 100% sure this belongs in the core, but I was unsure where it did belong For reference, the complaints that people have about using HTTP Auth are summarised in the following articles: http://www.artima.com/weblogs/viewpost.jsp?thread=155252 http://fishbowl.pastiche.org/2003/12/30/saving_http_authentication Some of their solutions involve changing RFCs. Mine only involves adding a configuration option which doesn't violate RFCs
An alternative solution to this can be implemented with this tiny patch: brock% cat files/require-auth.patch --- httpd-2.2.16/server/request.c.orig 2011-03-08 12:36:08.701398059 +0000 +++ httpd-2.2.16/server/request.c 2011-03-08 12:47:46.159477808 +0000 @@ -1631,6 +1631,11 @@ require_line *reqs; int i; + const char* auth_header = apr_table_get(r->headers_in, "Authorization"); + if (auth_header && strlen(auth_header)) { + return 1; + } + if (!reqs_arr) { return 0; } brock% This changes the requires_auth function to return true if the browser happens to have sent authentication credentials. The assumption here is that whatever resource is being protected will detect the authentication and apply whatever authorization is needed.
I haven't read the code, but the description makes it sound like this would work. Is there any chance it can be included in Apache?
Slightly confused. What standard are you referencing here?
(In reply to comment #3) > Slightly confused. What standard are you referencing here? I think rfc2617 is most relevant, although this really isn't a standards issue, it's an issue with the way apache configures and handles authentication. Currently, apache will only process an Authorization: header if there is a require directive on the request. My change above changes it so apache will always process an Authorization header. This allows a module or CGI program (or .asis file) to send a WWW-Authenticate challenge back to a client, but then have Apache handle the resulting Authorization header. Without this, the module/CGI program would have to re-implement the authentication code that is already in apache. For HTTP basic, this is a trivial effort, but Digest or Negotiate are both hard enough that it is attractive to use the existing code in Apache rather than re-implementing it. I have a program that sends a WWW-Authenticate header, and then I use this config: <Location /semiprivate> AuthType Kerberos #require valid-user Krb5Keytab /path/to/keytab KrbMethodK5Passwd off KrbAuthoritative off </Location> which, with the above patch, allows anonymous access until the program sends a WWW-Authenticate header, at which point browsers will send an Authorization header, and then Apache will authenticate them. Prior to the time the program sends the WWW-Authenticate header, the user can access resources in /semiprivate anonymously.
What you describe isn't a standards-issue, but the description of the issue ("Implement optional HTTP Authentication in a standards-compliant fashion") indicates that it is. Who is at cross-purposes here?
Sorry, that's my fault. The links provided in my first post suggest altering the standards. My point is that is possible to fix one of the problems that they list in their articles without altering the standards, and that's what I'm suggesting here. So what I'm saying is, "People have always thought that fixing the problem requires altering the standards, but I've found a way to do it without altering the standards". My apologies for any miscommunication.