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.
proposals: 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 checks 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 occur: 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 password fields. 3. The client posts the form back to the server. 4. The container attempts to authenticate the user using the information from the SECURITY 84 form. 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 information 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 ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]