> Why can't you write a filter that reads a config file and checks the > incoming URL to see if it is requesting an action that you would like to > restrict access to? How does that solution not solve your problem?
I originally opened WW-53 because WebWork does not let you secure your application in the standard way via web.xml. Adding a security filter does not solve this problem. The fundamental problem is that WebWork ignores the path, hence trying to protect a path via web.xml is made unnecessarily painful. One could argue that because of this WebWork is not even J2EE compliant. I have no idea why the decision was made for WebWork ignore the path (does anyone remember the reasoning?). IMHO it was a bad decision, however I guess it stays for backwards compatibility, but there needs to be a way to override this. Not everyone wants to write a filter. Not everyone even has that option - for example how would security implemented via filters propogate down to the EJB layer without resorting to using appserver specific calls? Anyway, I'm glad to see that WW-53 has been reopened and it looks like something will be done to address the issue. You're absolutely right in saying that WW doesn't need a secuirty framework - being able to lock the path should be all that is needed. Chris ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
