Jason,
------------------------------------------------------------------------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.
Maurice,
I think we need to be careful not to drive people away by being rude. If
you thought my idea for how to do this was too complex, then fine. But
the solutions you suggested, as Mike pointed out, do not solve the real
problem I was trying to highlight.
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
Jason
-----Original Message-----
From: Maurice C. Parker [mailto:maurice@;vineyardenterprise.com] Sent: Friday, November 01, 2002 8:29 PM
To: [EMAIL PROTECTED]
Subject: 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="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: 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
