You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Steve Vanspall <st...@crmsoftware.com.au> on 2002/12/06 02:59:19 UTC

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.

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.

Regards

Steve Vanspall


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Restriction of access to action/JSP's

Posted by Steve Vanspall <st...@crmsoftware.com.au>.
Thanks that is a big help.


Things seem to e falling into place.

Steve
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Friday, 6 December 2002 1:54 PM
To: Tomcat Users List
Subject: Re: Restriction of access to action/JSP's




On Fri, 6 Dec 2002, Steve Vanspall wrote:

> Date: Fri, 6 Dec 2002 12:59:19 +1100
> From: Steve Vanspall <st...@crmsoftware.com.au>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Restriction of access to action/JSP's

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Fri, 6 Dec 2002, Steve Vanspall wrote:

> Date: Fri, 6 Dec 2002 12:59:19 +1100
> From: Steve Vanspall <st...@crmsoftware.com.au>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>