tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: Form Authentication and status (response) code
Date Thu, 01 Sep 2011 23:06:27 GMT
That's the unfortunate way of form-based authentication.  It's an 
application convention rather than a protocol-level standard -- it's not 
a standard but rather a loose convention and has to be handled by the 
application code rather than seamlessly with at protocol handling level.

As such it's fine and good for consumption by interactive user sessions 
in a web browser -- as users can grok conventions just fine unless 
they're horrifically convoluted.

Unfortunately, for any other form of client (e.g. a programmatic, 
non-interactive service in the extreme case or even an interactive 
client that is not browser based but rather is written against some HTTP 
client library or another) form-based authentication is a royal mess.

It would be a lot better if form-based authentication standardized 
around returning a 401 -- ideally with some header information as to how 
to proceed to respond to the challenge.

Unfortunately, responding with a 401 is not really legal here and indeed 
results in bad behavior from some HTTP client libraries (e.g. that built 
into Java, for instance).

So form-based authentication is an obnoxious mutt -- but a mutt that 
everyone seems to have fallen in love with.

This isn't Tomcat's fault, however, and Tomcat is doing the normal thing 
by returning a 200 here.

As for tricks to see if your 200 isn't really a 200, you can:

 1. Check the response Content-Type if the expected Content-Type isn't
    one that could possibly be used by a login form or
 2. Add some other custom header to your response.  If it's not there
    but you got a 200, then something hijacked the response -- quite
    probably a login form.

Jess Holle

On 9/1/2011 5:49 PM, Mabry Tyson wrote:
> Summary: When requiring form authentication, Tomcat responds to an 
> unauthenticated GET request with a HTTP status code of 200 (OK) and 
> the login page.
> I believe that to be in violation of the HTTP standards.
> The problem:  Software makes a GET request to a web server.  It gets 
> back a 200 status code.  By RFC 2616, that code indicates "the request 
> has succeeded".
> The software then takes the resulting page as the successful response 
> to the GET request.   However, in some cases this response is NOT a 
> successful response
> but is instead a login form.
> By using a 200 status code, Tomcat is misrepresenting that the login 
> form is the response to the request.   My believe is a 4xx code 
> (client error) is appropriate, or possibly a 3xx code (Redirection) 
> might be appropriate.  Unfortunately, the RFC indicates that a 401 
> (Unauthorized) response MUST have a header that is only appropriate 
> for basic or digest authentication.  So a status code of 401 is not 
> legal in this situation.
> It seems unlikely that I'm the first to comment on this.  It must have 
> been discussed extensively before.   Can anyone tell me
>   (1) What is the reason behind saying the login form is a successful 
> response?
>   (2) Where is a pointer to the discussions?
>   (3) What is an appropriate (non-ad hoc) way to determine that Tomcat 
> is returning a login form rather than the requested resource?
> (I have done a quick search of the Internet, of Tomcat FAQ, and of 
> outstanding Tomcat bugs, but didn't find this.)
> For instance, here are the headers when doing a GET of a login 
> protected page from the examples shipped with Tomcat:
> > GET /examples/jsp/security/protected/index.jsp HTTP/1.1
> > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 
> OpenSSL/0.9.8r zlib/1.2.3
> > Host:
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Server: Apache-Coyote/1.1
> < Pragma: No-cache
> < Cache-Control: no-cache
> < Expires: Wed, 31 Dec 1969 19:00:00 EST
> < Set-Cookie: JSESSIONID=99FD7582647EEF539C449AEBBA5365EB; Path=/examples
> < Content-Type: text/html
> < Content-Length: 1413
> < Date: Thu, 01 Sep 2011 22:15:29 GMT
> while the content starts with
> <html>
> <head>
> <title>Login Page for Examples</title>
> <body bgcolor="white">
> <form method="POST" 
> action='j_security_check;jsessionid=99FD7582647EEF539C449AEBBA5365EB' >
> P.S.  For anyone maintaining the examples, shouldn't vendor examples 
> demonstrate the best practices?  I'd suggest you indicate the 
> Content-Type and the charset.
> Also, it would be handy if the web.xml showed how to have the login 
> page be served up by https (along with a note explaining that you 
> don't do it here since you don't know that https willl be available).
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message