That all makes sense, and thanks to you, Bob and Ted for your openness in discussing these issues with a non-commiter. In looking through the snapshot, I'm really excited to see where things are going, this framework is going to be a joy to work with.
dave On Tue, 2006-07-25 at 10:36 -0700, Don Brown wrote: > _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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
