Re: [OS-webwork] Re: Action invocation
Chris Nokleberg wrote: Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. That is a lot of extra machinery where pinning the action would work instead. A lot of extra machinery?! You declare what roles may access it in xwork.xml. One could even provide defaults at the package level. How is that a lot of extra machinery? Between skinning and support for declarative security, it seems to me the latter is wanted by more people. How do you know this? BTW, if interceptors had at least an optional URL-mapping component, you could do skinning via /* - DefaultSkinInterceptor /bar/* - BarSkinInterceptor So one should write an interceptor for a skin? Isn't that a little too much extra machinery? I find it strange how on one hand you argue against triggering functionality based on URL-matching, What argument are you talking about? AFAIK I haven't made any such argument. but on the other hand argue for that exactly through your skinning examples. Not following. What in the skinning examples is triggering functionality based on URL-matching? /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: Action invocation
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Chris Nokleberg wrote: Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. That is a lot of extra machinery where pinning the action would work instead. A lot of extra machinery?! You declare what roles may access it in xwork.xml. One could even provide defaults at the package level. How is that a lot of extra machinery? Creating an extra interceptor to re-create J2EE declarative security is at least some extra machinery compared to just using what is there. I'm not saying that it's bad, in fact I kind of like the idea of restricting which roles can run packages of actions, but I would prefer to add that IN ADDITION to being able to pin packages to certain URL paths to enable the use of J2EE declarative security and make it optional. It's sounding to me like we really need 2 configuration files here: 1) xwork.xml : the standard xwork configuration which applies to all Dispatcher types. This would include package and action configuration 2) xwork-web.xml : configures web specific configurations, such as URL paths to pin packages, and view mappings The reason I would say to put the view mappings in the xwork-web.xml is because you might want to use the same set of actions for web and Swing based apps, and you'd want to have different view mappings. Jason --- 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: Action invocation
Jason Carreira wrote: Creating an extra interceptor to re-create J2EE declarative security is at least some extra machinery compared to just using what is there. I'm not saying that it's bad, in fact I kind of like the idea of restricting which roles can run packages of actions, but I would prefer to add that IN ADDITION to being able to pin packages to certain URL paths to enable the use of J2EE declarative security and make it optional. It's sounding to me like we really need 2 configuration files here: 1) xwork.xml : the standard xwork configuration which applies to all Dispatcher types. This would include package and action configuration 2) xwork-web.xml : configures web specific configurations, such as URL paths to pin packages, and view mappings The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. The reason I would say to put the view mappings in the xwork-web.xml is because you might want to use the same set of actions for web and Swing based apps, and you'd want to have different view mappings. Interesting point. How many people would use it though? How realistic is that? /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: Action invocation
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. I'm planning on using Xdoclet, I don't know about you. :-) --- 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: Action invocation
On 3/1/03 7:25 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: Mike Cannon-Brookes wrote: Hrm - no, this is thinking the wrong way mate :) If webwork defined paths, security would work perfectly right? So why not have webwork only 'work' if the path is correct (and defined)? Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would execute nothing. Then the action would be pinned to that particular path, and skinning wouldn't work. I have _never_ needed to use the fact that actions can move paths, and I would hasten to guess that 95% of WebWork users don't care either? Leave the option open to do both, and we'll satisfy the security problems (by pinning paths). -mike PS IMHO the principle of least surprise here is that actions are NOT available anywhere. --- 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: Action invocation
Mike Cannon-Brookes wrote: I have _never_ needed to use the fact that actions can move paths, and I would hasten to guess that 95% of WebWork users don't care either? That might be so, yes. Leave the option open to do both, and we'll satisfy the security problems (by pinning paths). Make the path's optional then. Ok, that could work. PS IMHO the principle of least surprise here is that actions are NOT available anywhere. Maybe, maybe not. /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: Action invocation
Damn! A little late :(. - Original Message - From: matt baldree [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 9:56 AM Subject: Re: [OS-webwork] Re: Action invocation Can someone summarize the issues? If you build XWork the way you want what would be left out? I don't think we can build a framework that will meet everyone's needs and I don't think the new framework will be 100% backwards compatible with WW nor do I think it should be. I'd rather see a clean room design and see what desired requirements fall out. I think there are many ways to slice this. If we had a document defining the requirements, I think these discussions could be more productive. Rickard, could you draft a requirements document from your point of view and post it on WIKI? -Matt - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 8:46 AM Subject: Re: [OS-webwork] Re: Action invocation Jason Carreira wrote: The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. I'm planning on using Xdoclet, I don't know about you. :-) I'd probably use runtime attributes where possible, which is basically the same thing. That does take care of some of those issues, but it'd almost have to be mandatory for it to be practical to use. Ah well... personally I don't really care, since I have never used declarative security and will never use it either. Maybe it would be better if I did a framework for my own needs instead, and let you guys do what you is feel best in XWork. It seems we have very different requirements, much of it coming from the point that most of you seem to be doing straight web apps whereas I'm almost exclusively doing portlet-style apps with a lot of state machine-ish stuff. I have a lot of needs you don't have, and the other way round. /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 --- 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: Action invocation [state machine]
Rickard, You said it yourself, you're geared toward a state-machine-type of development. Well I am too, actually... heavily influenced by the OSWorkflow statemachine (I see large parallels between OSWF and WW -- especially with chaining). My point here is that I think you should stay around. With my help I think that we can address all the open issues, ignore all the jackass comments, and still get all your cool ideas in. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 6:46 AM Subject: Re: [OS-webwork] Re: Action invocation Jason Carreira wrote: The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. I'm planning on using Xdoclet, I don't know about you. :-) I'd probably use runtime attributes where possible, which is basically the same thing. That does take care of some of those issues, but it'd almost have to be mandatory for it to be practical to use. Ah well... personally I don't really care, since I have never used declarative security and will never use it either. Maybe it would be better if I did a framework for my own needs instead, and let you guys do what you is feel best in XWork. It seems we have very different requirements, much of it coming from the point that most of you seem to be doing straight web apps whereas I'm almost exclusively doing portlet-style apps with a lot of state machine-ish stuff. I have a lot of needs you don't have, and the other way round. /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 --- 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: Action invocation
Ah well... personally I don't really care, since I have never used declarative security and will never use it either. You might change your tune when you're asked to integrate your CMS product with an existing security framework... Especially if it's a large user base and they've gone with an enterprise security infrastructure based on something like Netegrity Siteminder. Those products will have integration with large app servers, etc., but you'd have to develop your own plugins. Using standard security frameworks allows you to more easily integrate with a whole security system. This is why I've pushed for us to stay with standard J2EE security rather than developing our own user / role framework. Jason --- 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: Action invocation
Can't we just add a path parameter to the action definitions in xwork.xml? Michael Blake Day Artistry Studios - e-commerce design, implementation and hosting email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mobile: 770.480.1547 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg Sent: Thursday, January 02, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Action invocation 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 --- 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: Action invocation
Mike Cannon-Brookes wrote: Hrm - no, this is thinking the wrong way mate :) If webwork defined paths, security would work perfectly right? So why not have webwork only 'work' if the path is correct (and defined)? Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would execute nothing. Then the action would be pinned to that particular path, and skinning wouldn't work. That way you keep .action, AND your security works fine? Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. /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: Action invocation
On Fri, Jan 03, 2003 at 09:25:43AM +0100, Rickard Öberg wrote: Mike Cannon-Brookes wrote: Hrm - no, this is thinking the wrong way mate :) If webwork defined paths, security would work perfectly right? So why not have webwork only 'work' if the path is correct (and defined)? Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would execute nothing. Then the action would be pinned to that particular path, and skinning wouldn't work. That way you keep .action, AND your security works fine? Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. That is a lot of extra machinery where pinning the action would work instead. Between skinning and support for declarative security, it seems to me the latter is wanted by more people. BTW, if interceptors had at least an optional URL-mapping component, you could do skinning via /* - DefaultSkinInterceptor /bar/* - BarSkinInterceptor I find it strange how on one hand you argue against triggering functionality based on URL-matching, but on the other hand argue for that exactly through your skinning examples. -Chris --- 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: Action invocation
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: Action invocation
You can put a declarative security line for */deleteUser.action, can't you? Not to say that this is good, in fact it's horrible, but at least it COULD work. -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Action invocation 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/asdas dasd/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 --- 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: Action invocation
Hrm - no, this is thinking the wrong way mate :) If webwork defined paths, security would work perfectly right? So why not have webwork only 'work' if the path is correct (and defined)? Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would execute nothing. That way you keep .action, AND your security works fine? (And if you don't define paths - it works as it does now - principle of least surprise!) -mike On 3/1/03 6:05 AM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: 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 --- 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: Action invocation
May be we can add explicit url to action mapping instead of relying on using the success view. For e.g, something like: url path=/admin/deleteUser.jsp action-ref name=admin.deleteUser/ /url Or that can be implemented as part of a servlet filter configuration. Regards, Low --- Rickard_Öberg [EMAIL PROTECTED] wrote: 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 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.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
