You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Geddes, Mark (ANTS)" <ma...@ants.co.uk> on 2001/06/13 18:41:32 UTC

Declarative security constraints

I am using the <security-constraint> tag in web.xml to protect access to my
pages.
I have been unable to use this method to restrict access to specific
requests, say 'action1.do'. I assume this is because only the resources are
protected (i.e. the actual JSPs).
The upshot is that I am protecting the whole web-app using
<url-pattern>/*</url-pattern>.
This is fine. It is an intranet site and it means that I can use
request.isUserInRole() and request.getUserPrincipal() in the confidence that
I know the user has been forced to authenticate themselves.
The problem comes when I want to restrict certain actions based upon the
user's role. In the perform() method of my Action class I have to use
request.isUserInRole(). I would like to be able to do this declaratively
rather than programmatically, either using the <security-constraint>
declaration in web.xml, or possibly as part of the <action> declaration in
struts-config.xml.
 
Question1: Have I missed something obvious in my use of the
<security-constraint> mechanism?
Question2: If not, would this make a useful extension to the Struts
framework?
 
Thanks in advance.
 
Mark




***************************************************************************
This email message contains confidential information for the above addressee only.  If you are not the intended addressee you must not disclose or use the information in any manner whatsoever.

Any opinion or views contained in this email message are those of the sender, do not represent those of the Company in any way and reliance should not be placed upon its contents.

Unless otherwise stated this email message is not intended to be contractually binding.  Where an Agreement exists between our respective companies and there is conflict between the contents of this email message and the Agreement then the terms of that Agreement shall prevail.

Abbey National Treasury Services plc. Registered in England. Registered Office:  Abbey House, Baker Street, London NW1 6XL.  Company Registration No: 2338548.  Regulated by the SFA
***************************************************************************

Re: Declarative security constraints

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

On Wed, 13 Jun 2001, Geddes, Mark (ANTS) wrote:

> I am using the <security-constraint> tag in web.xml to protect access to my
> pages.
> I have been unable to use this method to restrict access to specific
> requests, say 'action1.do'. I assume this is because only the resources are
> protected (i.e. the actual JSPs).
> The upshot is that I am protecting the whole web-app using
> <url-pattern>/*</url-pattern>.
> This is fine. It is an intranet site and it means that I can use
> request.isUserInRole() and request.getUserPrincipal() in the confidence that
> I know the user has been forced to authenticate themselves.
> The problem comes when I want to restrict certain actions based upon the
> user's role. In the perform() method of my Action class I have to use
> request.isUserInRole(). I would like to be able to do this declaratively
> rather than programmatically, either using the <security-constraint>
> declaration in web.xml, or possibly as part of the <action> declaration in
> struts-config.xml.
>  
> Question1: Have I missed something obvious in my use of the
> <security-constraint> mechanism?

Have you tried a URL pattern like this?

  <url-pattern>/action1.do</url-pattern>

The syntax of URL patterns used in security constraints is exactly like
that used in servlet mappings, and this would be an exact match pattern
for path "/action1" (assuming you are using the usual *.do mapping for the
controller servlet).

> Question2: If not, would this make a useful extension to the Struts
> framework?
>  

I've thought about the idea of incorporating role-based checking into the
controller servlet itself, but it seems like a duplication of what you can
already do in the container (such as the above).  However, a place where
it might be useful is if you have a scripted workflow of some sort, and
certain steps would be executed or skipped based on the roles possessed by
the authenticated user.

> Thanks in advance.
>  
> Mark
> 

Craig McClanahan