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? Martin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
