Is there anything on <action> that allows restricting roles? I
remember this being in S1 and I'm unsure if it exists in S2. If not,
it's something I believe we should add as I believe it's useful when
using CMA. When using Spring Security, I generally keep all my
configuration in my context file, but I can see why it's useful when
using CMA. If it is an attribute, I suppose having separate <action>
definitions is the best way to allow different roles for different
methods? If not, I could see some sort of "method:role1/role2"
shortcut being useful - but it might also make things more
complicated.
Matt
On Dec 9, 2007 5:30 AM, Don Brown <[EMAIL PROTECTED]> wrote:
> Since the commit for this feature involved a rather large XWork change
> (properly immutable configuration objects [1]), I decided to commit
> what I have and discuss the next steps.
>
> First, due the aforementioned fix [1], Brian, your SmartURL's
> migration work will probably be most affected. I changed the
> configuration objects to be immutable using a static inner builder
> class pattern. This makes construction a bit tricker, so pay
> attention to the changes in the code and tests for the codebehind
> plugin. The bright side is the construction code is much more
> readable and nasty state bugs should be gone. You can do nifty things
> like this:
>
> ActionConfig config = new ActionConfig.Builder("mypackage", "foo/*/*",
> "foo.BarAction")
> .methodName("execute")
> .addParam("someparam", "someval")
> .addResultConfig(new
> ResultConfig.Builder("success{1}", "foo.MyResult")
> .addParams("location", "/foo.jsp")
> .build())
> .build();
>
> As for the allowed methods, I originally suggested three options:
>
> 1. A new property/constant titled 'struts.restrictToDeclaredMethod'
> that will instruct the ActionConfig (where the allowedMethods property
> lives) to only allow the method that is explicitly defined (defaults
> to 'execute'). If false, all methods will be allowed.
>
> 2. A new attribute on the <action> element called 'allowedMethods',
> which takes a comma-separated list of method names to allow
>
> 3. A new @ActionMethod annotation for the codebehind plugin that
> declares a method as callable
>
> And after the comments, I see #2 is important and #3 I'll skip, since
> Brian will be rewriting that stuff anyways.
>
> To answer Matt's concern, yes, the default will be all public, no-arg
> methods can be called, but what this will allow folks to do is limit
> the methods that can be called, if they so choose. It also makes it
> clearer to the developer what methods are being exposed through tools
> like the config browser plugin. I'm also thinking it will be helpful
> down the road when a plugin wants to move behind no-arg methods (I've
> tried it, it can be pretty powerful).
>
> See https://issues.apache.org/struts/browse/WW-2363
>
> Any more thoughts?
>
> Don
>
> [1] http://jira.opensymphony.com/browse/XW-594
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
http://raibledesigns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
