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="success">foo.jsp</view> <view name="input">fooform.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="success">foo.jsp</view> <view name="input">fooform.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="success">foo.jsp</view> > <view name="input">fooform.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="Default" path="/" packages="webwork.test"> >>>> <action name="FormTest" alias="formtest"> >>>> <view name="success">redirect.action?url=jdom.action</view> >>>> <view name="input">formtest.jsp</view> >>>> </action> >>>> >>>> <action name="jdom.JDOMTest" alias="jdom"> >>>> <view name="success">jdom.jsp</view> >>>> </action> >>>> </actionset> >>>> </actions> >>>> >>>> Foo.xml: >>>> <action name="Foo1" alias="foo1"> >>>> <view name="success">foo.jsp</view> >>>> <view name="input">fooform.jsp</view> >>>> </action> >>>> <action name="Foo2" alias="foo2"> >>>> <view name="success">foo.jsp</view> >>>> <view name="input">fooform.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 > > > > ------------------------------------------------------- > 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: 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
