tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Tulley" <>
Subject [Proposal] error page handling on authorization failure
Date Fri, 04 Apr 2003 01:11:12 GMT
Right now when a resource is secured, after the user enters their
credentials, if the credentials are not authenticated, a user-specified
error page is shown, specified from web.xml.
But, if the authentication happens correctly and the user is not in the
role so the authorization fails, this same error page is NOT displayed,
but rather a 403 error, "Access to the requested resource has been
denied".  At that point, the session already has authenticated
credentials, and it is impossible to hit back and try again.  You either
get "j_security_check is unavailable", or repeat 403 errors, depending
on what you try to do.  Your only recourse is to close the browser and
start a new session.

1) If possible, on authorization failure, dump the authenticated user
credentials, as if we never tried to authenticate
2) Redirect to the same error page when there is an authorization
failure but authentication success.

The spec says this:

"SRV.12.5.3 Form Based Authentication
When a user attempts to access a protected web resource, the container
the user's authentication. If the user is authenticated and possesses
authority to
access the resource, the requested web resource is activated and a
reference to it is
returned. If the user is not authenticated, all of the following steps
1. The login form associated with the security constraint is sent to
the client and
the URL path triggering the authentication is stored by the container.
2. The user is asked to fill out the form, including the username and
3. The client posts the form back to the server.
4. The container attempts to authenticate the user using the
information from the
5. 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 401.
6. If authentication succeeds, the authenticated user's principal is
checked to see
if it is in an authorized role for accessing the resource.
7. If the user is authorized, the client is redirected to the resource
using the stored
URL path.
The error page sent to a user that is not authenticated contains
about the failure.

So, it is ambiguous, and does not specify what to do.  It also does not
forbid it.  Also, this error is hard to deal with as is, so I do not
think that we would be breaking backwards compatibility to suddenly
start handling it.  At least, if we are, it would probably be greeted as
a welcome change, not a bad one.

This really should be dealt with in the spec, preferrably with a
separate page for each type of failure, or at least outright specifying
that the one page should be used for both cases.

What do you all think?  It seems like this should be an easy fix, as
well, though I could be wrong.

Jeff Tulley  (
Novell, Inc., The Leading Provider of Net Business Solutions

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message