Just like bug #12194, for Tomcat 3 When a web app contains an error page for code 401 like <error-page> <error-code>401</error-code> <location>/401.html</location> </error-page> The "WWW-Authenticate" Header is not sent, causing agents not to prompt for credentials. When no "error-page", Tomcat behaves as expected. So this code never works : oResponse.setHeader("WWW-Authenticate", "BASIC realm=\"Intranet\""); oResponse.sendError(HttpServletResponse.SC_UNAUTHORIZED); Using Apache 1.3 + mod_jk + Tomcat 4.1.12 + IBM JDK 1.3.1.
Thi is a dupe of a 4.0.x bug, I think. The spec doesn't require supporting error pages for internal container status codes (as per an answer given by Craig). The problem here is that we have to reset the response to some kind of knwon state. It was proposed that only the critical headers be reset during the operation. See the ErrorDispatcherValve for more info. If you could submit a patch, that would help (otherwise, this won't get fixed anytime soon).
I finaly got the WWW-Authenticate header by changing org.apache.coyote.tomcat4.CoyoteResponse to keep that header, I'm attaching a patch with my change
Created attachment 7880 [details] Keeping the WWW-Authenticate header in reset(int, String)
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...
That workaround is easy for BASIC authentication but I'm using DIGEST and generating the WWW-Authenticate header is not trivial. And don't forget you can always forward or redirect to do custom authentication with either a JSP or a servlet.
Yet another solution is to call RequestDispatcher.forward after setting the return code to 401, auth header etc to send the client the HTML (or whatever) you want them to see if they give up trying to authenticate. My vote (if I have one) is that since there are lots of workarounds and the current behviour is so clean that this isnt a bug at all.
*** This bug has been marked as a duplicate of 18040 ***