You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jeff Tulley <JT...@novell.com> on 2003/05/12 20:57:35 UTC

Re: [Patch] Handling of authentication success but authorizationfailure

Actually, I forgot to consider the basic authentication case with that
patch.  It seems easy enough with the second half of my fix, I just send
the same old error message if there is no error page defined.  That
seems to work.  But, my code:

Session session = getSession(hrequest);
session.setPrincipal(null);

seems to hang the basic authentication process.  Does anybody know of a
better way to clear out the user credentials/principal that would work
with both types of authentication?  I'll keep researching it and
hopefully submit a better patch soon.

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

>>> JTULLEY@novell.com 5/12/03 11:44:10 AM >>>
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

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


Re: [Patch] Handling of authentication success but authorizationfailure

Posted by Remy Maucherat <re...@apache.org>.
Jeff Tulley wrote:
> Actually, I forgot to consider the basic authentication case with that
> patch.  It seems easy enough with the second half of my fix, I just send
> the same old error message if there is no error page defined.  That
> seems to work.  But, my code:
> 
> Session session = getSession(hrequest);
> session.setPrincipal(null);
> 
> seems to hang the basic authentication process.  Does anybody know of a
> better way to clear out the user credentials/principal that would work
> with both types of authentication?  I'll keep researching it and
> hopefully submit a better patch soon.

I was about to post an objection about the difference in behavior with 
BASIC.
If it can be made to be consistent between auth methods, I would be ok 
to consider making the change to Tomcat 5.

Other improvements could be considered for FORM auth (and make it behave 
exactly like BASIC from the user perspective, which is the goal, using 
forwards instead of redirects).

Remy


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