Re: [s2] Allowed methods next step
On 12/11/07, Brian Pontarelli [EMAIL PROTECTED] wrote: At first I thought this might be a problem because SmartURLs was sub-classing the ActionConfig object in order to add some additional information for performance reasons. However, I have a feeling that I can remove the sub-class. All the same, I think your change still allows sub-classing. Now I just need to figure out if I want to remove my sub-class or not :) Yeah, try to do it without the subclass, and feel free to add more builder methods as needed. I've got some work done on the new convention plugin and put together a short design doc for it because I kept getting lost in the soup of conventions and configuration overrides. Here's the URL for the design doc: http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-convention-plugin/design.txt?view=markup Yep, looks fine to me. With respect to allowed methods, the new plugin only generates configuration for the execute method and any other method that is annotated. So, with the new allowedMethods property inside the ActionConfig, it should be a snap to just ensure that when the plugin is constructing the ActionConfig instances it locks down the Action accordingly. Cool. To be honest, I'm thinking that maybe the feature would be better simply as an Interceptor, and therefore, I might end up ripping it out this weekend. Doing it as an interceptor would certainly be the most flexible and consistent with how other features work. Don -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Allowed methods next step
Don Brown 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();
At first I thought this might be a problem because SmartURLs was
sub-classing the ActionConfig object in order to add some additional
information for performance reasons. However, I have a feeling that I
can remove the sub-class. All the same, I think your change still allows
sub-classing. Now I just need to figure out if I want to remove my
sub-class or not :)
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.
I've got some work done on the new convention plugin and put together a
short design doc for it because I kept getting lost in the soup of
conventions and configuration overrides. Here's the URL for the design doc:
http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-convention-plugin/design.txt?view=markup
With respect to allowed methods, the new plugin only generates
configuration for the execute method and any other method that is
annotated. So, with the new allowedMethods property inside the
ActionConfig, it should be a snap to just ensure that when the plugin is
constructing the ActionConfig instances it locks down the Action
accordingly.
-bp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Allowed methods next step
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]
Re: [s2] Allowed methods next step
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]
Re: [s2] Allowed methods next step
CMA = container managed authentication for those who haven't memorized
every three letter acronym under the sun.
What about using an s2 interceptor to enforce role security? That way
you could have an implementation for whatever security mechanism your
using and it's not tied to the struts configuration. I suppose we could
still have a place to store role metadata in the configuration, but I
wouldn't want the specific security enforcement logic to be tied to the
s2 itself.
Tom
Matt Raible wrote:
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Allowed methods next step
On Dec 9, 2007 9:44 AM, Tom Schneider [EMAIL PROTECTED] wrote:
CMA = container managed authentication for those who haven't memorized
every three letter acronym under the sun.
What about using an s2 interceptor to enforce role security?
This is what I've done in the past. Yes, it works. However, I think
this is something we should ship out-of-the-box to make it easier for
newbies. The interceptor can use request.isUserInRole() and if you're
using a non-standard security mechanism, you can create a filter and
requestwrapper that allows this to work for your security framework.
This is what Acegi/Spring Security and many others do and I think it's
the best solution.
Matt
That way
you could have an implementation for whatever security mechanism your
using and it's not tied to the struts configuration. I suppose we could
still have a place to store role metadata in the configuration, but I
wouldn't want the specific security enforcement logic to be tied to the
s2 itself.
Tom
Matt Raible wrote:
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]
-
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]
Re: [s2] Allowed methods
I'm confused - why don't we just allow public methods to be called? Matt On Dec 5, 2007, at 1:06 PM, Don Brown wrote: I'm about to commit a fairly large patch that, among other things, adds built-in support for limiting what methods can be invoked on an Action. My motivation was actually to improve the ability for the REST plugin to introspect what HTTP methods are supported (automatic HTTP OPTIONS and WADL support), but I'd imagine the primary use will be as a security feature to prevent any arbitrary action being executed. The default behavior is to introspect the Action class during startup to get a list of all methods that can be executed. This allows, among other things, the config-browser plugin the ability to display exactly what methods are being automatically exposed to users. My question is, how best should this capability be exposed? A couple of ideas: 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 I'm thinking about doing all three, but I'm not sure #2 is necessary. I want to minimize XML configuration as much as possible, and I'm not convinced #2 is worth the extra config. Any other ideas? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Allowed methods
3. A new @ActionMethod annotation for the codebehind plugin that
declares a method as callable
Does it make sense to collapse the SU ActionNames and ActionName
annotations into this new annotation? This annotation could provide
additional parameters to control the URLs for the method. If we do this,
it should probably be called Action rather than ActionMethod.
@Action(urls={foo, bar})
We could also add a number of features to this annotation such as
HTTP-methods:
@Action(httpMethods={POST})
And support for namespaces:
@Action(urls={/ns1/foo, /ns2/bar})
-bp
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [struts-dev] [s2] Allowed methods
Don Brown wrote: 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 I'm thinking about doing all three, but I'm not sure #2 is necessary. I want to minimize XML configuration as much as possible, and I'm not convinced #2 is worth the extra config. For those of us that have not changed everything over to annotations and still use struts.xml, #2 would be key... For example, any struts2 app kickstarted by appfuse 1.9 uses ?method:METHOD_NAME to support a cancel button for CRUD editing, so it would be appropriate to add cancel into the action definition for that CRUD save action. Without #2 such projects would need to allow #1 non-declared methods, but wouldn't have a way to restrict to just cancel. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Allowed methods
I'm about to commit a fairly large patch that, among other things, adds built-in support for limiting what methods can be invoked on an Action. My motivation was actually to improve the ability for the REST plugin to introspect what HTTP methods are supported (automatic HTTP OPTIONS and WADL support), but I'd imagine the primary use will be as a security feature to prevent any arbitrary action being executed. The default behavior is to introspect the Action class during startup to get a list of all methods that can be executed. This allows, among other things, the config-browser plugin the ability to display exactly what methods are being automatically exposed to users. My question is, how best should this capability be exposed? A couple of ideas: 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 I'm thinking about doing all three, but I'm not sure #2 is necessary. I want to minimize XML configuration as much as possible, and I'm not convinced #2 is worth the extra config. Any other ideas? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Allowed methods
Don Brown wrote: 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 I'm thinking about doing all three, but I'm not sure #2 is necessary. I want to minimize XML configuration as much as possible, and I'm not convinced #2 is worth the extra config. Any other ideas? I appreciate this change. Just a quick note for #2 that action name=name method=method should automatically allow that specified method and disallow execute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
