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: Restriction of access to action/JSP's
Date Fri, 06 Dec 2002 02:53:48 GMT


On Fri, 6 Dec 2002, Steve Vanspall wrote:

> Date: Fri, 6 Dec 2002 12:59:19 +1100
> From: Steve Vanspall <steve@crmsoftware.com.au>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subject: Restriction of access to action/JSP's
>
> Ok I think I can pinpoint my question a bit more now.
>
> I know I need to code my own filter for this.
>
> What I need to find out, is, how does Tomcat decide which of it's users (in
> tomcat-users.xml) can access different actions.
>

Tomcat looks at the URL patterns in your <security-constraint> element(s).
If the context-relative part of the request URL matches, it enforces the
<auth-constraint> and/or <user-data-constraint> clauses associated with
that <security-constraint>.  Note that all of this is based solely on the
original request URL -- security constraints are *not* applied on request
dispatcher includes and forwards.

> presumably there is a setting for the action itself. Or perhaps for a group
> of URL's
>
> if it's for the action itself, is there a way to access that actions
> properties in java. Does Struts ro tomcat store them somewhere, and can I
> acces the information from a filter. That way, I could check the user level,
> and decide what to do with the response.
>

Struts, like any application, can perform dynamic security checks in
addition to those performed by container, by calling:
* request.getRemoteUser() - to get the username of the logged-in user
* request.getUserPrincipal() - to get the Principal object representing
  the logged-in user (advanced use cases only)
* request.isUserInRole() - to check whether the logged-in user
  possesses the specified role name

In particular, Struts uses the last of these method calls if you include a
role attribute on your <action> definition.  You can, in your own servlets
and filters, do exactly the same thing if you want to.

Note that there is no way for an application-level filter to dynamically
define user and role information *before* the container applies security
constraints.  All of that happens before any user-level filters or
servlets are ever invoked.

> Regards
>
> Steve Vanspall

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