On Fri, 6 Jun 2003, Martin Naskovski wrote:
> Date: Fri, 6 Jun 2003 16:57:08 -0700
> From: Martin Naskovski <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
> Martin Naskovski <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: <logic:present roles="..."> tag - how to specify permissions (on
> top of roles)?
>
> Hi all - I have the following issue w/Struts' (or maybe even the Servlet
> API) role-based security model.
>
> If I had something like this in a JSP:
>
> <logic:present roles="user, admin">
> show an input field to change your password
> </logic>
>
> how can I - within the current confines of Struts (1.1) and the Servlet API
> (2.3), instead of hardcoding the roles in the JSP (user, admin) where a
> password change field (or some other common function across a set of roles)
> is presented, do something like the following:
>
> <logic:present permission="changePassword">
> show an input field to change your password
> </logic:present>
>
> I know the "permission" attribute currently does not exist, however, IMHO,
> this (permissions based on roles) is a very valid concept. So, instead of
> defining a "changePassword" _role_, I would have a 'changePassword'
> permission, which would be shared among a number of roles. Clearly, being
> an admin or a user is a _role_ whereas changing a password is a permission
> (or a functionality or a function...)
>
> I don't see anything of this nature that would facilitate this in Struts,
> or Resin, which is what we are using to do our development... So I'm
> wondering, has someone else encountered a this issue and how did they
> resolve it?
>
> Does JAAS alleviate some of this? Does it apply to Resin 2.1.x somehow?
>
JAAS doesn't have anything to do with this -- however, there is a
little-known feature of container-managed authorization that should help
you out in at least *some* of these use cases -- role links.
The basic idea is that an application "hard codes" it's own notion of what
role identifiers mean; but it turns out that the server you are deploying
onto has a different meaining for those things. To solve this, you can
tweak the web.xml file with an element like this, inside the <servlet>
element for ActionServlet:
<servlet>
<servlet-name>Struts Controller Servlet</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
...
<security-role-ref>
<role-name>foo</role-name>
<role-link>bar</role-link>
</security-role-ref>
</servlet>
What this means, essentially, is that "if the Struts Controller Servlet
asks if a user has role "foo", the container should really check for role
"bar" instead. Using this, adapting the differences between how an
application is coded and how the security infrastructure is really set up
is not a problem.
Note that security roles are defined on a per-servlet basis, so the above
setting covers any checks of roles by the Struts Controller Servlet
itself (and that means it covers checking the "role" attribute of <action>
elements). If you want to use things like <logic:present role="foo"> in
your JSP pages, you'll need to define individual <servlet> elements for
them as well.
> Thank you.
> Martin
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
