Hi,If you are already using container-managed security (i.e. <security-constraint> elements in the web.xml file), then you have the following basic options:
I am pretty new to Struts. Looked through the archives and wasn't sure what the current answer would be to my question.
Is there a way to use Struts while using the declarative approach to security? Not to add another user, but simply to secure your application resources. Or one of the side-effects of Struts is that you are forced to either extend ActionServlet or do something similar and therefore not use declarative security provided by the container?
Your help in clarifying this matter would be greatly appreciated.
* If the resources you are worried about are static things like HTML pages
and images, define security constraints for them in the usual way. This
has nothing to do with Struts; it's just standard practice for container managed
security.
* If the resources you are worried about are Struts actions, there are two fundamental (but non-exclusive) approaches:
- You can define a security constraint that protects the particular Struts action you are worried about. For example, if you are using extension mapping and you want to protect the "/foo" action, you would create a security constraint for URL "/foo.do".
- You can include a "role" attribute in the <action> element, which asks Struts to ensure that the user has the appropriate role before Struts allows him or her to execute this action.
- You can check inside your Action.execute() method for a particular role, by calling the servlet-standard request.isUserInRole() method.
* Your concern isn't that a user can display a particular page; it's that you
want to dynamically limit the contents of the page based on security
constraints:
- In the action, you can use request.isUserInRole() as above.
- In a JSP page, you can use <logic:present role="..."/> around the markup that should be generated only if you have one of the roles specified.
As you can see, there are pretty comprehensive facilities in Struts to leverage container managed security to meet your needs.
Craig McClanahan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
