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
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
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
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,
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
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.
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
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
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
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
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
11 matches
Mail list logo
