-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason,
On 8/6/2009 8:33 AM, Jason Royals wrote:
> Thanks for the advice, but I think <security-role-ref> is only valid
> within the context of a <servlet> element though? As such, it wont work
> on JSP's or other resources that might do a
> request.isUserInRole("admin") but are not servlets themselves (such as
> filters and listeners).
You might be able to get away with re-defining the JSP Servlet and
including the <security-role-ref>, but you're right: that won't cover
filters or listeners. It's a shame the spec is written in this way.
As for André's comment about the top-levelness of <security-role-ref>,
Chuck points out that it's <servlet>-specific, but does not say where
that is defined. I found it very quickly by looking at the 2.3 servlet
DTD (http://java.sun.com/dtd/web-app_2_3.dtd) which contains this
documentation:
"
<!--
The security-role-ref element contains the declaration of a security
role reference in the web application's code. The declaration consists
of an optional description, the security role name used in the code,
and an optional link to a security role. If the security role is not
specified, the Deployer must choose an appropriate security role.
The value of the role-name element must be the String used as the
parameter to the EJBContext.isCallerInRole(String roleName) method
or the HttpServletRequest.isUserInRole(String role) method.
Used in: servlet
- -->
<!ELEMENT security-role-ref (description?, role-name, role-link?)>
"
Searching for actual uses of security-role-ref confirms that it is only
valid within a <servlet> element. :(
> I'd also like to avoid changing anything in
> web.xml if possible. Configuring the container is fine (eg, server.xml)
> but messing around too much in the application WAR package could be
> trouble.
I know you mentioned you don't want to mess around with web.xml but I
think you'll probably have to do it. If you're willing to do that, you
could write a filter that wraps the request and overrides isUserInRole
to provide a look-up-table of mapped group names. Something like this:
public class GroupRenamingFilter
implements Filter
{
private Map roleNameMap; /* fill this yourself */
public void invoke(ServletRequest request, ServletResponse,
FilterChain chain)
{
if(request instanceof HttpServletRequest)
request = new GroupRenamingRequest((HttpServletRequest)request);
chain.doFilter(request, response)
}
private class GroupRemaningRequest
extends HttpServletRequestWrapper
{
public GroupRenamingRequest(HttpServletRequest wrapped)
{
super(wrapped);
}
public boolean isUserInRole(String roleName)
{
String realRoleName = (String)roleNameMap.get(roleName);
if(null == realRoleName)
realRoleName = roleName; // not sure what to do, here
return super.isUserInRole(realRoleName);
}
}
}
Now that I've written it, I think you'll need to implement this as a
Valve that is invoked /before/ Tomcat's authorization code runs (which
may not be possible?).
On the other hand, what's wrong with a search-and-replace within the
web.xml to change the names of the security-role names to those you
actually use instead of the more generic "users" and "admins"?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkp69AUACgkQ9CaO5/Lv0PC6qQCaAi3L37mYx5zBU50GUB675qdJ
dRsAoK6UoU7hpjMjvnNQwFVRLM7TAOOG
=zPlp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
