DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13430>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13430 WWW-Authenticate Header Is Not Sent ------- Additional Comments From [EMAIL PROTECTED] 2003-09-16 19:12 ------- We were able to solve this in our local applications by turning the 401.html page into a 401.jsp and adding the following code: response.setHeader("WWW-Authenticate", "BASIC realm=\"myrealm\""); This caused the browser to once again display the authentication dialog. If the user presses "cancel", or fails login multiple times, the browser gives up on the dialog and displays the underlying HTML in the 401.jsp file. If they succeed in authenticating, they are directed to the originally requested page. IMO, the ability to *entirely* override the authentication process is a valuable tool, but the way it was specified in web.xml is very confusing. What we are doing here is entirely delegating the authentication to an external JSP or servlet. This is a great tool, because it allows you to make dynamic decisions that you can't do inside of web.xml. For example, you could send a "WWW-Authenticate: BASIC" to most systems, but if the request matches a certain pattern or if it comes from a specified IP, etc, you could instead send a "WWW-Authetnicate: Digest"; or perhaps you could send a redirect to force SSL. Anyhow, it's a nice tool to be able to extend the functionality here. The problem is that the way the user above stumbled across this (and the way I stumbled across it, too) is by having a preexisting login-config to use BASIC auth, and then later added the 401.html page. My intent here was to display a link that allows the user to reset his or her password and have it emailed back to the email associated with their account. I was *very* confused when adding the error-page mapping completely disabled my login-config. Perhaps there is a better way to document this functionality? It seems to me that this is a reasonably common desire among developers: To use BASIC auth but to still provide user friendly tools when the user fails authentication. My recommendation is that this bug be marked "WONTFIX", but that the documentation be updated to explain it more clearly. Implementing Juan's patch would take away the ability to delegate the whole authentication process to another JSP, which would be a loss. I just wish it were easier to understand... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
