For example the following new method:
RequestDispatcher.isAuthorized()
Returns true if the RequestDispatcher's url passes the constraints defined in web.xml
-Tim
Craig R. McClanahan wrote:
On Thu, 9 Jan 2003, Jeffrey Winter wrote:Date: Thu, 9 Jan 2003 19:25:37 -0500 From: Jeffrey Winter <[EMAIL PROTECTED]> Reply-To: Tomcat Users List <[EMAIL PROTECTED]> To: Tomcat Users List <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
