You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mabry Tyson <Ty...@AI.SRI.COM> on 2011/09/02 00:49:30 UTC
Form Authentication and status (response) code
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication and status (response) code
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jess,
On 9/1/2011 7:06 PM, Jess Holle wrote:
> 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.
The servlet spec (section 13.6.3 "Form Based Authentication") has the
whole process laid out, except that they don't say what the HTTP
response code should be when a request for a protected resource
arrives and the login form should be "sent to the client".
Later, it says:
"
If authentication fails, the error page is returned using either a
forward or a redirect, and the status code of the response is set to 200.
"
Ignoring the fact that you can't do a redirect using a 200 response,
it's clear that there is no "unauthenticated" or "forbidden" response
code to be used, here. Presumably, the decision to use response code
200 was drawn from this section as well as practical considerations
(being able to prohibit the login form from being directly accessible
to remote clients for instance) and past user input (I think Tomcat
used to issue a redirect, but now does an internal forward and
responds with 200).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5hTEwACgkQ9CaO5/Lv0PBpKACbB5A+XQ42NDT9gHSgR7jCDEAz
5i0An2JZMwf+jrrpwuQrk6AtDWbpOYpN
=XYT8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication and status (response) code
Posted by Jess Holle <je...@ptc.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Form Authentication and status (response) code
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/9/2 Mabry Tyson <Ty...@ai.sri.com>:
> 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.
neither is 403 or 404. Plus add to that that certain web browser (IE)
has a habit to display his own error page instead on the one provided
by the server.
The response code 200 tells that server is returning some valid data
(a HTML page) that has to be displayed to the user. There might be
other headers along that (e.g. to forbid caching).
What is your software trying to do? It is trying to crawl the web
site? Maybe you can detect the presence of login form on the HTML
page that is returned to you?
> 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.
The best way to make examples better is to prepare and propose patches
(through Bugzilla).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org