tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Jacobson <>
Subject Re: front controller pattern and security
Date Fri, 14 Jun 2002 08:00:05 GMT
John Gregg wrote:

> Hi all.
> I've been thinking about how the j2ee front controller pattern (used by
> Struts et al.) does/does not take advantage of url-based authorization
> constraints in web.xml.  I want to avoid having to check roles in my own
> code as much as possible.  At first I thought I could declare a URL like
> /somewebapp/somerole/* to require the "somerole" role before being allowed
> access to my controller servlet.  Another URL would be
> /somewebapp/someotherrole/* but would map to the same servlet.  That servlet
> would then pick off the action at the end of the URL and execute it.
> However, while I can restrict access to the servlet, or whatever other
> "physical" resource I'm trying to protect, what I really want to protect is
> the action that's executed.  Am I just stuck with enumerating all possible
> actions in by web.xml (/somewebapp/somerole/someaction,
> /somewebapp/somerole/someotheraction, etc.)?  Should I instead make a filter
> that enforces this for me?  I'm facing the same problem with Apache SOAP's
> rpcrouter.

Surely, the way you describe, using servlet-mapping & auth-constraint 
does exactly what you want?
In other words, you have one (controller) servlet declared, and you use 
servlet-mapping to declare all urls that invoke that servlet. In 
auth-contstraint you declare the mapping between urls and user roles. 
So, when a user invokes /app/manager/ac_details, the auth-constraint 
would trigger an authorisation check to make sure the user was in the 
indicated role. Then (if he's allowed), because the servlet-mapping maps 
this url to the controller servlet, the controller servlet is invoked, 
and, as you say, you can then determine what the action was (ac_details) 
by examining the url. This method does not restrict access to the 
controller servlet directly, but does protect the functions to be performed.

Or have I misunderstood?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message