_If_ you use a wildcard for an action, and _if_ you have that matched value as
your method name, then yes, you are intentionally allowing anyone to access any
method on that action class. This isn't a concern, IMO, because it was
explicitly allowed by the developer, where the old capability was enabled by
default, where the developer may not have been aware of it.
In the future, I could see an interceptor that checks the method specified for a
method-level annotation, and only if it is present, allow the request to continue.
Don
David Evans wrote:
On Mon, 2006-07-24 at 21:27 -0400, Ted Husted wrote:
On 7/24/06, David Evans <[EMAIL PROTECTED]> wrote:
I understand the security concerns, but the flexibility is far more
important to me. If a user wants to protect themselves, they can make
methods they don't want run by xwork private. Or maybe have an explicit
list of <param name="excludeMethods">this,that,theOther</param>.
The framework is as flexible as ever. Action alaises are still
supported. The only difference is that you can only declare the alias
in an action mapping, or use wildcards.
I think the action:name!method idiom is perfectly flexible. I was
referring specifically to Bob's comments about securing the method names
available for calling, by using struts tags which will assign a digest
key to a map of method names. Bob said "I was hoping we'd store which
methods are OK to invoke in the session or sign them or something".
The question is, once the wildcard is set up in the struts.xml file, to
allow the above idiom, how do you prevent the calling of a method on
your action? because anyone can then type:
http://www.domain.com/someaction?action:someaction!somemethod to try to
run random methods. I am hoping that if any steps are taken to prevent
that security hole, it will still allow the flexible wildcard usage.
Instead of
MyDispatchAction!delete
We define an action mapping
<action name="delete" class="example.CrudAction" method="delete">
and call the delete acton directly, or simulate the same with wildcards.
The URL aliases weren't more "flexible". Just lazy and unsecure.
For the configuration-free crowd, I expect alias annotations are (or
will be) supported too.
What would that look like? I don't know what is meant by alias
annotations.
dave
-Ted.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
