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: xxx.example.com
> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
