tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: Authentication and Filters
Date Fri, 10 Jan 2003 02:15:12 GMT
Is there a chance (or worthwhile) that in Servlet API 2.5 a developer 
could check if an obtained RequestDispatcher would violate a security 
constraint in web.xml?

For example the following new method:
Returns true if the RequestDispatcher's url passes the constraints 
defined in web.xml


Craig R. McClanahan wrote:
> On Thu, 9 Jan 2003, Jeffrey Winter wrote:
>>Date: Thu, 9 Jan 2003 19:25:37 -0500
>>From: Jeffrey Winter <>
>>Reply-To: Tomcat Users List <>
>>To: Tomcat Users List <>
>>Subject: Authentication and Filters
>>I am using a Filter to do some URL rewriting.  In the
>>filter, I accept a url like:
>>    /user/x/resource/y     [1]
>>and convert it to
>>    /resource/y?user=x     [2]
>>In the Filter, I create a RequestDispatcher using the
>>new url, and then call forward().
>>The servlet setup to handle "/resource" is set up for
>>Basic authentication in web.xml.  It works fine when
>>calling the resource directly, that is, using url [2].
>>The servlet is called and the authentication works.
>>However, when requesting through the filter using
>>url [1] via POST (which is converted to [2]) the
>>authentication appears to be unavailable to the
>>servlet.  That is, Tomcat is obviously authenticating
>>correctly because it is getting to the servlet's
>>doPost() method, but when I call
>>    Principal principal = request.getUserPrincipal();
>>inside of doPost(), "principal" is equal to null.
>>It's as if the Filtering process is somehow clearing
>>the Principal value out of the HttpServletRequest object
>>even though it has been authenticated.
>>Oddly, this works fine with GET; the url rewriting is
>>done correctly, and  calling getUserPrincipal()
>>returns a value that contains the username.
>>Am I doing something wrong?  Is this a known bug or has any
>>one else seen this problem?
> A key rule to remember is that security constraints are applied *only* on
> the original URL requested by the client -- not on RequestDispatcher
> calls.  I would bet you probably have "/resource/*" protected, but you'll
> likely want to protect "/user/*" as well.
> Craig

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

View raw message