tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Authentication and Filters
Date Fri, 10 Jan 2003 01:43:34 GMT


On Thu, 9 Jan 2003, Jeffrey Winter wrote:

> Date: Thu, 9 Jan 2003 19:25:37 -0500
> From: Jeffrey Winter <jeffreywinter@attbi.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> 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.

> Thanks.

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message