Re: [OS-webwork] Re: Re: Action invocation
Matt Ho wrote: I look at it this way. There are a couple accepted ways of implementing declarative security: 1. Securing based on path (Servlets for example) 2. Securing based on authenticated role (EJBs for example) There are of course proprietary implementations. Ideally, I would love XWork to support 1 and 2 orthogonally. I can understand forcing developers to rely on approach 1 as it's a common web practice, but I can't agree with forcing developers to use approach 2 only. snip This would essentially mean that XWork would have to support these two invocation types: /action/bar /foo/bar.action The first case would work well with path based security and roles, and the other would have no choice but to use roles. However, feature-wise the second case supports skinning. And then there's the third case which also supports path based security: /foo/xyzzy.jsp (which invokes bar action) Maybe it's possible to support all three. Question is: is it better to support as many options as possible, or is it better to have one way to do things? I suppose it's a tradeoff between flexibility and complexity. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Re: Action invocation
This would essentially mean that XWork would have to support these two
invocation types:
/action/bar
/foo/bar.action
I'm probably not explaining myself well. To me, these are both examples
of path based security, struts style. Your second example with the jsp
was what I was considering role based security.
I'd like to propose the following approach as a potential solution.
Below are two examples of what modified actions.xml files (or whatever
xworks uses) might look like:
Let's assume for both these examples that a Filter is being used. The
traditional Servlet controller doesn't support a /foo/xyzzy.jsp
implementation.
Example 1:
In this example, our Servlet filter is mapped to *.action so that a
request to http://somesite.com/{context}/some.action invokes the
SomeAction while
http://somesite.com/{context}/xzy/another.some.action
invokes AnotherAction. The security role would be optional and
could
also be specified inside the body of the action tag if the xwork
was
to support multiple roles.
action name=com.indigoegg.SomeAction alias=/some role=xyz
view name=input/WEB-INF/views/some-input.jsp/view
view name=success/WEB-INF/views/some-success.jsp/view
/action
action name=com.indigoegg.AnotherAction alias=another.some
view name=input/WEB-INF/views/another-input.jsp/view
view name=success/WEB-INF/views/another-success.jsp/view
/action
Example 2:
In this example, our Servlet filter is mapped to *.jsp so that
requests
for /foo/xyzzy.jsp are intercepted by the filter. A couple things
changed in our configuration. The first is the addition of an
action-mapping section.
action name=com.indigoegg.SomeAction ref=some/
view name=input/WEB-INF/views/some-input.jsp/view
/action
action-mapping
action-refsome/action-alias
url-pattern/foo/xyzzy/url-pattern
!-- apply security here --
/action-mapping
Example 3:
This example combines both styles and maps to *.jsp. In this case,
a request for /path.jsp would map to /WEB-INF/views/some-success.jsp
whereas a request for /foo/xyzzy.jsp would be directed to
/foo/xyzzy.jsp
action name=com.indigoegg.Bar alias=/path ref=bar/
view name=success/WEB-INF/views/some-success.jsp/view
view name=input/WEB-INF/views/some-input.jsp/view
/action
action-mapping
action-refsome/action-alias
url-pattern/foo/xyzzy/url-pattern
!-- apply security here --
/action-mapping
While I think the style in Example 2 is very flexible, it comes at the
cost of increased configuration file complexity.
--
Matt Ho
Principal
Indigo Egg, Inc.
http://www.indigoegg.com/
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Re: Action invocation
Chris Miller wrote: What would happen if the skins had to be explicitly defined in the configuration, or if none were defined then XWork would default to pinned paths? Then there would be an outcry of too much to configure.. waaah. :-) That way people that were not using the skinning would be able to use declaritive security as in a normal webapp, while the skinners could still use it to with relatively minor inconvenience - they'd have to declare a separate security constraint for each skin, eg: web-resource-collection web-resource-nameManagement Application/web-resource-name url-pattern/admin/*/url-pattern url-pattern/skin1/admin/*/url-pattern url-pattern/skin2/admin/*/url-pattern http-method*/http-method /web-resource-collection So those paths would then be duplicated in xwork.xml? Doesn't sound very appealing to me. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
FW: [OS-webwork] Re: Re: Action invocation
Did anyone have any thoughts on this skin / package config stuff I sent this morning? -Original Message- From: Jason Carreira Sent: Friday, January 03, 2003 9:47 AM To: '[EMAIL PROTECTED]' Subject: RE: [OS-webwork] Re: Re: Action invocation -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 6:06 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Re: Action invocation Chris Miller wrote: What would happen if the skins had to be explicitly defined in the configuration, or if none were defined then XWork would default to pinned paths? Then there would be an outcry of too much to configure.. waaah. :-) What if we just had the skins defined either at a global level, or at a package by package level (or even down to the action, if needed). Sorry, I've forgotten the exact details of Rickard's XML config stuff skins skin name=default root=/WEB-INF/jsp/default/ skin name=neon root=/WEB-INF/jsp/neon/ /skins package name=default classes=com.example.actions skin=default view type=ERROR/WEB-INF/jsp/error.jsp/view action name=common class=CommonAction view type=INPUTcommon.jsp/view view type=SUCCESScommon.jsp/view /action /package package name=foo classes=com.example.actions.foo extends=default path=/foo action name=foo1 class=FooOne view type=INPUTfoo1.jsp/view view type=SUCCESSfoo1.jsp/view /action /package package name=neonfoo extends=foo path=/neon/ This shows a couple of ideas: 1) The skins are defined at the top and define the base path to look under for pages 2) Packages have paths which define the URL path under the webapp for which they apply (to make path based security easy) 3) Packages with no path are not directly executable, so you can have your default package which cannot be accessed, and only holds common config information for its children 4) Packages inherit from their parent packages, so that all 3 packages have a common action defined 5) The neon package has both common and foo1 actions defined, and needs to have JSPs under /WEB-INF/jsp/neon for error.jsp, common.jsp, and foo1.jsp --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Re: Re: Action invocation
OK, I must be missing something here... I'm sure we discussed this previously and the only solid argument in support of the arbitrary paths was for skinning applications. I still can't see how the path/skinning functionality can be supported by having urls that end with .jsp instead of .action. Can you explain further (with an example perhaps) what you mean by If .action invocations are not allowed then it's possible to use declarative security? How does your approach allow web.xml to be configured to protect a path such as */admin/*? Rickard Öberg [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Re: Action invocation
I use #2 quite a bit, and I'm not in any sort of portlet environment. I just have multiple ww:action tags in my JSPs. - Original Message - From: Hai Pham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 2:12 PM Subject: Re: [OS-webwork] Re: Re: Action invocation Hi all, I think there are two major reasons why Rickard wants to discard URL with .action. 1. to get declarative security working 2. to make it possible to invoke multiple read-only actions within a page (in portlet environment for example) IMO, only #1 is reaonable. Still, lots of us already implement authentitation filter to get around the prob. with the path. That's not to say that we need not to fix that, but IMO there should be better way then getting rid of .action URL. #2 is most often applicable in portlet environment. In my project I don't need to use any action tag or #action macro. I believe this is true for the majority of other projects. Even if you want to do that, there are althernatives like Sitemesh or even ww:include tag. Rickard's comment about .action URL unstable (for bookmarking) and exposing the implementation is unconvincing to me. In fact, .action URL is more stable than a .jsp or something like that. You can map an action to various views like jsp, velocity... So even when you change the view name or view type, the URL is still the same. Well, that's my thought. I just hope that if you insist on these new implementation (related to portlet thingy), you still keep .action URL around and that its performance wouldn't be degraded. --- Chris Miller [EMAIL PROTECTED] a écrit : OK, I must be missing something here... I'm sure we discussed this previously and the only solid argument in support of the arbitrary paths was for skinning applications. I still can't see how the path/skinning functionality can be supported by having urls that end with .jsp instead of .action. Can you explain further (with an example perhaps) what you mean by If .action invocations are not allowed then it's possible to use declarative security? How does your approach allow web.xml to be configured to protect a path such as */admin/*? Rickard Öberg [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork = --- Hai Pham Quang --- __ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Re: Action invocation
Hi all, I think there are two major reasons why Rickard wants to discard URL with .action. 1. to get declarative security working 2. to make it possible to invoke multiple read-only actions within a page (in portlet environment for example) IMO, only #1 is reaonable. Still, lots of us already implement authentitation filter to get around the prob. with the path. That's not to say that we need not to fix that, but IMO there should be better way then getting rid of .action URL. #2 is most often applicable in portlet environment. In my project I don't need to use any action tag or #action macro. I believe this is true for the majority of other projects. Even if you want to do that, there are althernatives like Sitemesh or even ww:include tag. Rickard's comment about .action URL unstable (for bookmarking) and exposing the implementation is unconvincing to me. In fact, .action URL is more stable than a .jsp or something like that. You can map an action to various views like jsp, velocity... So even when you change the view name or view type, the URL is still the same. Well, that's my thought. I just hope that if you insist on these new implementation (related to portlet thingy), you still keep .action URL around and that its performance wouldn't be degraded. --- Chris Miller [EMAIL PROTECTED] a écrit : OK, I must be missing something here... I'm sure we discussed this previously and the only solid argument in support of the arbitrary paths was for skinning applications. I still can't see how the path/skinning functionality can be supported by having urls that end with .jsp instead of .action. Can you explain further (with an example perhaps) what you mean by If .action invocations are not allowed then it's possible to use declarative security? How does your approach allow web.xml to be configured to protect a path such as */admin/*? Rickard Öberg [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork = --- Hai Pham Quang --- __ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Re: Action invocation
I think there are two major reasons why Rickard wants to discard URL with .action. 1. to get declarative security working [snip] IMO, only #1 is reaonable. Still, lots of us already implement authentitation filter to get around the prob. with the path. That's not to say that we need not to fix that, but IMO there should be better way then getting rid of .action URL. As a recent struts to WebWork convert, I was surprised to find that http://somesite.com/path/bar.action was exactly the same as http://somesite.com/path/foo/bar.action to webwork. While I've seen a couple posting asking this same question, I haven't seen an answer. I agree with Hai and a number of the other posters that this goes a long way to fixing the security issue. I look at it this way. There are a couple accepted ways of implementing declarative security: 1. Securing based on path (Servlets for example) 2. Securing based on authenticated role (EJBs for example) There are of course proprietary implementations. Ideally, I would love XWork to support 1 and 2 orthogonally. I can understand forcing developers to rely on approach 1 as it's a common web practice, but I can't agree with forcing developers to use approach 2 only. Production environments may combine a variety of different technologies. If a company already has a system that utilizes path based security (1), they shouldn't be forced to declare security in two places. Likewise, if EJB style security is already being used, it'd be nice to have the option of using that with their XWork actions. Note - I'm not proposing that we using EJB style security declarations, I'm just using it as an example of tying security to the action performed rather than the path requested. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
