Let's not play at semantics here with pedantic trivialities. Replace "can't support J2EE declarative security" with "only supports J2EE declarative security in a way which is so cumbersome as to be unusable in a non-trivial system" and re-read it. The point isn't that it's impossible to use web.xml, but that it's made unusable in any practical sense because of the way the current setup works. You'd have to either:
A) come up with a naming convention such as *Buyer.action to secure for buyers B) Have a separate web.xml entry for each action and each alias Of these, A) is probably the most usable option, but hardly meets the goals of separating deployment concerns for security and development concerns. B) is just ridiculous if you get over 10 actions or so, as you'll probably have at least as many aliases. This is simply NOT manageable. In our current app, we have over 400 handlers (the equivalent of an action in the framework we currently have to use). So, for the classes plus aliases, we're talking over 800 entries we'd have to have in web.xml. Is the "declare each action in your web.xml separately" option really the best practice you want to put out there for Webwork for securing apps using J2EE declarative security? Jason -----Original Message----- From: Maurice Parker [mailto:maurice.parker@;pmic.com] Sent: Monday, November 04, 2002 11:22 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements Jason Carreira wrote: >----------------------------------------- (on viruswall) > >email-body was scanned and no virus found >--------------------------------------------------------- > > >----------------------------------------------------------------------- >- > >I guess that's possible, but it's not really the point. J2EE provides >declarative security that works well enough, and that's what we're >using. I can tell you now that if Webwork can't support J2EE >declarative security, I won't be able to get it in here, and I'm sure >there are a lot of other shops where that will also be the case. As a >framework which supports servlet development, Webwork should support >the J2EE security framework, even if it allows people to bypass it and >do their own security implementations. > > J2EE decaritive security for a web application is taken configured via your web.xml file. To say that WebWork doesn't support this is patently false. It is very possible to use you web.xml file to restrict access to your Actions. It's your opinion that it's too inconvient to declare each action in your web.xml separately and you want to do it based on directory wildcards. We will probably add the ability only reference alias' by thier absolute pathname in a future version, but I think it highly unlikely that you will configure permissions in you actions.xml. In the meantime either configure you Actions individually in you web.xml file or write you own filter to do directory based restriction. -Maurice >Security products have a vested interest in plugging into app server >security frameworks, but probably won't support a webwork security >framework without having to go in and code the interconnects ourselves. > >Jason > > >-----Original Message----- >From: Maurice Parker [mailto:maurice.parker@;pmic.com] > >Sorry if I was overly harsh, but the fact that WebWork will not >integrate a security framework has been discussed and decided upon more >than once. > >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? > >-Maurice > > > >------------------------------------------------------- >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 > ------------------------------------------------------- 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 ------------------------------------------------------- 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
