Bug 13430 - WWW-Authenticate Header Is Not Sent
WWW-Authenticate Header Is Not Sent
Status: RESOLVED DUPLICATE of bug 18040
Product: Tomcat 4
Classification: Unclassified
Component: Catalina
4.1.12
All All
: P3 normal with 5 votes (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2002-10-09 00:13 UTC by Vincent-Olivier Arsenault
Modified: 2005-03-24 14:39 UTC (History)
2 users (show)



Attachments
Keeping the WWW-Authenticate header in reset(int, String) (515 bytes, patch)
2003-08-18 19:09 UTC, Juan Carlos Estibariz
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent-Olivier Arsenault 2002-10-09 00:13:39 UTC
 
Comment 1 Vincent-Olivier Arsenault 2002-10-09 00:18:31 UTC
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.
Comment 2 Remy Maucherat 2002-10-09 06:02:16 UTC
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).
Comment 3 Juan Carlos Estibariz 2003-08-18 18:58:28 UTC
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 
Comment 4 Juan Carlos Estibariz 2003-08-18 19:09:40 UTC
Created attachment 7880 [details]
Keeping the WWW-Authenticate header in reset(int, String)
Comment 5 Justis Peters 2003-09-16 19:12:03 UTC
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...
Comment 6 Juan Carlos Estibariz 2003-09-16 19:44:32 UTC
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. 
Comment 7 sam 2004-05-18 17:26:22 UTC
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.
Comment 8 Mark Thomas 2005-03-24 23:39:17 UTC

*** This bug has been marked as a duplicate of 18040 ***