Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-Id: <sebf891a.033@prv-mail20.provo.novell.com>
Date: Mon, 12 May 2003 11:44:10 -0600
From: "Jeff Tulley" <JTULLEY@novell.com>
To: <tomcat-dev@jakarta.apache.org>
Subject: [Patch] Handling of authentication success but authorization
	failure
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_5E01D26A.355412A7"

--=_5E01D26A.355412A7
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

A while back I proposed some changes to how Tomcat handles the case
where it is supplied a valid user name that does not belong in the
correct role to access a secured resource.  I finally had time to make
the code changes associtated with my proposal.

What tomcat currently does:
The user is authenticated successfully, and the user's principals are
put in the session.  Then, upon authorization failure, an "Access to the
requested resource has been denied" error is sent back to the browser. 
Since the user principals are in the current session, you cannot hit the
browser back button to retry a login.  You have to close out the browser
and try again.  This is a very annoying and confusing state.

The attached patch solves this problem by doing two things:

1) Upon authorization failure, the user principals are cleared from the
session
2) Instead of sending back a browser error, a redirect to the
"form-error-page" specified in web.xml is performed.

I propose at very least committing part one of my fix, to get the
browser out of the weird authenticated but not authorized state.  

I also propose that Tomcat do a redirect to the error page instead of
sending back the less friendly message.  The Servlet Specification does
not address this issue, and does not specify behavior one way or
another.  If there are any Tomcat committers on the JSR committees for
the next Servlet specification, I think it would be good to see if the
spec could be made more clear on this point.  Lacking guidance by the
spec, I feel that redirecting to the same error page for both
authentication and authorization failures provides at least some level
of control by the application developer.

Thanks,

Jeff Tulley  (jtulley@novell.com)
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

--=_5E01D26A.355412A7
Content-Type: text/plain; name="AuthenticatorBase.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="AuthenticatorBase.txt"

Index: AuthenticatorBase.java
===================================================================
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.37
diff -u -r1.37 AuthenticatorBase.java
--- AuthenticatorBase.java	19 Mar 2003 01:33:17 -0000	1.37
+++ AuthenticatorBase.java	12 May 2003 17:20:13 -0000
@@ -537,6 +537,8 @@
             if (debug >= 1)
                 log(" Calling accessControl()");
             if (!accessControl(hrequest, hresponse, constraint)) {
+                Session session = getSession(hrequest);
+                session.setPrincipal(null);
                 if (debug >= 1)
                     log(" Failed accessControl() test");
                 // ASSERT: AccessControl method has already set the appropriate
@@ -631,10 +633,11 @@
                 return (true);
         }
 
-        // Return a "Forbidden" message denying access to this resource
-        ((HttpServletResponse) response.getResponse()).sendError
-            (HttpServletResponse.SC_FORBIDDEN,
-             sm.getString("authenticator.forbidden"));
+        String contextPath = this.context.getPath();
+        String errorURI = contextPath + config.getErrorPage();
+        HttpServletResponse hres =
+          (HttpServletResponse) response.getResponse();
+        hres.sendRedirect(hres.encodeRedirectURL(errorURI));
         return (false);
 
     }


--=_5E01D26A.355412A7
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--=_5E01D26A.355412A7--