Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
On Wednesday, Nov 6, 2002, at 09:51 Europe/London, Rickard Öberg wrote: The issue about actions.xml is verbosity, not being able to figure out how to create it. Having a DTD doesn't change a thing in this regard. XDoclet, perhaps? /Rickard, who still uses views.properties :) Regards, Simon --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
Exactly my point, you can make the configuration method support a lot of power but only require simple configuration. Now, multiple config files could possibly confuse users, no doubt about that. I don't think I'd like that. Good thing that configuration is pluggable, so any kind of config is support-able. The main thing, as my main point has always been, is that the internal workins will need to be beefed up. But that's a post-1.3 thing we can discuss more about when the time comes. -Pat It's about scalability, and in this case scaling down to simpler projects. If it's scaling _down_ you're worried about, surely making as many elements and attributes as possible optional is the Right Way? The actions.xml that's part of the source covers enough ground to allow a newbie to get started (from experience :) and seems to cover most of the obvious things that a user would like to do. An alternative: if each Action has a small config file specifying its views associated with it (in the same style as Hibernate), and this is documented in the javadocs for the Action and ActionSupport classes, then the problem of not being able to create it is trivialised. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Webwork Security Requirements
Or we could have the webwork.action.packages property set the root packages to search from, so that if you have an action foo.bar.Foo1, and webwork.action.packages=foo, then a url like http://example.com/bar/Foo1.action would look for bar.Foo1, then foo.bar.Foo1. In other words, use the part of the package after the set prefixes as the path to the action in the url. Alias's could be created either in the same package (alias=foo1) or in a different package (alias=/bar2/foo1). Then the JSP's could be found the same way they are now, based on the path (in this case looking in /bar for JSP views). This would allow you to know what paths your actions are going to be executed under, so you can secure them. Jason -Original Message- From: Maurice C. Parker [mailto:maurice;vineyardenterprise.com] Sent: Saturday, November 02, 2002 7:29 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements This is Jira issue WW-53 (http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-53). I have stored the meatiest portions of this thread there so that we can remember this stuff for a future release. Here's my comment that I attached in Jira: Mike's last suggestion is much more palatable. Perhaps it could even be boiled down further. If we add concept of relative vs. absolute addressing to aliases then you wouldn't even need the new attribute. This would be using the action in the current directory: action name=Foo1 alias=foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action This would only allow you to access the action in it's absolute address: action name=Foo1 alias=/secure/blah/foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action That still leaves the issue of using actual class names as actions. Perhaps in a distant future release require that the alias be used and not allow the direct utilization of classnames. -Maurice On Friday, November 1, 2002, at 08:54 PM, Mike Cannon-Brookes wrote: Actually - I'm not sure I agree. Personally, I see the 'non path mapped' nature of WebWork actions as a flaw. I haven't found one good use for them yet. I would love to see something to stop actions from moving. I think the configuration can be made very simple - it need not be as complex as Jason listed here. action name=Foo1 alias=foo1 path=/secure/blah view name=successfoo.jsp/view view name=inputfooform.jsp/view /action Just an optional path element is all that's really needed - there could also be a 'default path' attribute at the top of the file actions - that's not really a lot of complexity for such a needed feature is it? -mike On 2/11/02 12:28 PM, Maurice C. Parker ([EMAIL PROTECTED]) penned the words: Guys, Adding more junk to the Actions.xml is a sure way fire way to make using WebWork more difficult. Do a comparison of our mapping file and Struts and you will see what I'm talking about. Jason, we've been over this repeatedly. People on the list have given you many helpful suggestions to solve your problem ranging from writing a security filter to clever web.xml configurations. You have been given a solution, it's now up to you to implement it. -Maurice On Friday, November 1, 2002, at 06:40 PM, Patrick Lightbody wrote: Jason, I agree. I believe that configuration in WebWork is one area of improvement that should be addressed in the next version. I'll jot up some ideas I've had as well as yours. Maybe if we get a Wiki set up soon we can drop stuff there. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: Opensymphony-Webwork@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Friday, November 01, 2002 1:06 PM Subject: [OS-webwork] Webwork Security Requirements I'm hoping that at the beginning of next year we'll be able to replace the web framework we're using (a proprietary one built by the consultants we brought in to get us kick-started) with Webwork. One of the drop dead requirements is going to be easy integration with J2EE declarative security. We need to be able to secure paths using deployment descriptors. Right now this is impossible in webwork because of the way paths are used: not as paths for finding actions, but as paths for finding JSPs. You can run an action from any path, if you know its name. I'm not sure of the best way to handle this in Webwork, but I would think this is a common requirement for J2EE apps, and most users won't want to have to write a security framework like Atlassian did for Jira. One possible solution would be to be able to break the config files up into multiple configuration files (good for multi-developer concurrent development anyway) and be able to assign each of these config files a path that they configure the app for. So you have Actions.xml: actions actionset name=foo path=/foo configfile=foo.xml/ actionset name
RE: [OS-webwork] Webwork Security Requirements
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
Re: [OS-webwork] Webwork Security Requirements
snip Why not just provide two ServletDispatchers? One that works the way everything does now (but just reading views.properties) and another that reads a mapping file that maps path to WebWork alias/action: mapping.properties: /secure/Foo.action=Foo views.properties Foo.action=Foo This could be done right now by just writing your own MappedServletDispatcher, maybe someone should write it and then contribute it back to OpenSymphony. This is a perfect example where we can add more features without complicating the basic principle of keeping up-front usage simple. That's my two cents, but of course, I'll go with whatever the core WebWork decide. -Pat --- 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
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
In general idea, I'm all for it. However, I think actions.xml has many problems itself. For example, the fact that commands are built in to the configuration DTD even though commands are an optional piece included in ActionSupport. See my blog entry a while back for an example configuration (a bit verbose, but the idea is there). Maybe we could take something like that and trim it down? http://radio.weblogs.com/0108886/2002/09/15.html -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 04, 2002 9:30 AM Subject: Configuration (was RE: [OS-webwork] Webwork Security Requirements) What are the current thoughts on moving to one form of configuration (i.e. getting rid of views.properties and just using actions.xml)? -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Monday, November 04, 2002 12:24 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements Oh, good! I just thought two different ServletDispatchers would be nice to offer flexibility, but maybe only one is needed. Either way, doing it this way is nice also because internal actions are now not exposed at all. One of these days we might want to rename views.properties, since it's not views at all anyone, but action definitions. In fact, I'd be all for requiring an action to be aliased before it can be used (not more looking in the package). I alias all my actions before using them. This sorta goes back to my original hope that configuration be simplified and make much more sense in version 2.0. -Pat --- 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
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
+1! Pat is a god! (He told me to say that so I'm blindly worshipping him.) Actually... I still vote +1, and Pat's just another frood in PsychoDelusionLand. - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant On Mon, 4 Nov 2002, Patrick Lightbody wrote: No, it's the same problem that we had in the past (before GenericDispatcher). The solution that was proposed is to use the redirect.action (when I get it working that is). And for 1.3 I think that's fine. I was thinking about this some more and actually, maybe consolidating views.properties and actions.xml is actually the _wrong_ way to go. Instead, why not do something similar to what happens today, except make a few changes: - keep global configuration (a la webwork.properties) seperate from action configuration (a la views.properties) - allow the configuration (XMLActionConfiguration vs PropertiesConfiguration) to be specified in the global configuration, or default to PropertiesConfiguration if not given (so things stay simple, right?) - Change the configuration architecture so that the example I posted in my weblog is supported. This basically means that internally, Foo!someCommand means nothing. Instead, the configuration (again, this is internally) actually is generic enough like the config I gave in my weblog. Then PropertiesConfiguration can read views.properties like it always did, and translate Foo!someCommand as the class is Foo and pass a property key/value pair of command=someCommand in before executing. Before you shoot it down as overly complex, remember that externally, things are as simple as always, but power users (like me) can write a better XMLConfiguration that takes advantage of the new, powerful, (internal) configuration architecture. -Pat - Original Message - From: Maurice Parker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 04, 2002 10:41 AM Subject: Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements) Patrick Lightbody wrote: As for parsing whether the result is an action or a view, it's not that it's non-trivial, it's that it's impossible, since the user might want either behavior! It better not be impossible. All that GenericDispatcher code you added tries to do that today, and requires the ability to do so to function correctly. If it's impossible, I can't see how we can include it in the upcoming 1.3 release and have zero defects. -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
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
Again, as if this hasn't been reiterated enough times. simplicity is key. People like views.properties, why not keep them happy? It's like the propertytag debate. People like the idiosyncratic way it worked, why modify it just to enforce some arbitrary perception of correctness? s/people/webwork developers I have had plenty of discussions with lots of people in #java about the property tag and it's pretty much universal that the current behaviour is wierd at best. (Like the ww:propertyfoo:bar//ww:property instance: does that print or just push? That depends on the output of foo:bar/!). And again, I am not for changing anything, I want to add a logical and simple system, one that will fix the dreaded issue in jira about wanting ww:property value=foo/ to push, because doing that isn't possible at all with the current tags but would be trivial with two tags ww:value and ww:render (or push/print, or use/out or whatever name you prefer). I really do like Maurice's approach of keeping things as simple as possible. I likewise feel that everyone should develop an instant knee-jerk reaction AGAINST adding more configuration options for users to be befuddled by, and that it should be viewed as a distasteful last resort. Remind me again who is suggesting we replace views.properties with the xml file. // Anders Hovmöller --- 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
Re: [OS-webwork] Webwork Security Requirements
Guys, Adding more junk to the Actions.xml is a sure way fire way to make using WebWork more difficult. Do a comparison of our mapping file and Struts and you will see what I'm talking about. Jason, we've been over this repeatedly. People on the list have given you many helpful suggestions to solve your problem ranging from writing a security filter to clever web.xml configurations. You have been given a solution, it's now up to you to implement it. -Maurice On Friday, November 1, 2002, at 06:40 PM, Patrick Lightbody wrote: Jason, I agree. I believe that configuration in WebWork is one area of improvement that should be addressed in the next version. I'll jot up some ideas I've had as well as yours. Maybe if we get a Wiki set up soon we can drop stuff there. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: Opensymphony-Webwork@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Friday, November 01, 2002 1:06 PM Subject: [OS-webwork] Webwork Security Requirements I'm hoping that at the beginning of next year we'll be able to replace the web framework we're using (a proprietary one built by the consultants we brought in to get us kick-started) with Webwork. One of the drop dead requirements is going to be easy integration with J2EE declarative security. We need to be able to secure paths using deployment descriptors. Right now this is impossible in webwork because of the way paths are used: not as paths for finding actions, but as paths for finding JSPs. You can run an action from any path, if you know its name. I'm not sure of the best way to handle this in Webwork, but I would think this is a common requirement for J2EE apps, and most users won't want to have to write a security framework like Atlassian did for Jira. One possible solution would be to be able to break the config files up into multiple configuration files (good for multi-developer concurrent development anyway) and be able to assign each of these config files a path that they configure the app for. So you have Actions.xml: actions actionset name=foo path=/foo configfile=foo.xml/ actionset name=Default path=/ packages=webwork.test action name=FormTest alias=formtest view name=successredirect.action?url=jdom.action/view view name=inputformtest.jsp/view /action action name=jdom.JDOMTest alias=jdom view name=successjdom.jsp/view /action /actionset /actions Foo.xml: action name=Foo1 alias=foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action action name=Foo2 alias=foo2 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action Or something. Any other thoughts on how this could be done? I think this is VERY important for (Web|X)work Jason Carreira -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
