If something like this was implemented, I'd hope that there would be a way for those of us who use JSTL to still be able to specify method names.
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>. my .5 cents. dave On Mon, 2006-07-24 at 16:23 -0700, Bob Lee wrote: > I agree it's a security concern, and it still is if the developer uses a > path pattern, except in the latter case, it's harder for us to secure. > > I was hoping we'd store which methods are OK to invoke in the session or > sign them or something. For example, we could have tags like this: > > <s:link action="Foo" method="bar">...</s:link> > > <s:submit method="tee">Update</s:submit> > > Now the user doesn't have to worry about the extension used for actions and > we can secure it. For example, we might generate a URL like this for the > first link: > > Foo!123424587425.action > > where "123424587425" is the key to the method name in the session. Or: > > Foo!bar-2455464566.action > > Where "2455464566" is the digest of "Foo!bar" with a private key. > > Bob > > On 7/24/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > The problem is that prefix allows anyone to specify the method to be > > called on > > the action through the URL, any URL. I'd argue it is a security concern, > > so the > > developer should have to work at explicitly allowing a method to be > > arbitrarily > > called. > > > > Don > > > > Bob Lee wrote: > > > I think "method:foo" might still make sense. It's orthogonal to path > > > mappings. Maybe. > > > > > > Bob > > > > > > On 7/24/06, David Evans <[EMAIL PROTECTED]> wrote: > > >> > > >> On Mon, 2006-07-24 at 15:15 -0700, Don Brown wrote: > > >> > David Evans wrote: > > >> > > I was looking in DefaultActionMapper and am wondering about the > > >> > > compatibilityMode switch functionality. In getMapping > > >> compatibilityMode > > >> > > is used to see whether to check for the ! method idiom. I assume > > this > > >> is > > >> > > because it will eventually be removed because wildcard mappings > > make > > >> it > > >> > > redundant. But in the constructor, the PrefixTrie that's being set > > up > > >> is > > >> > > also checking the compatibilityMode switch to see if it should add > > a > > >> > > node for the "method:" prefix. Should that be there? Is there > > someway > > >> in > > >> > > which you can use wildcards in your mapping in order to replace the > > >> > > parameter prefix? So that the button the user clicks will determine > > >> > > which method is run? > > >> > > > >> > The problem we are addressing is the ability to explicitly specify > > the > > >> method to > > >> > be invoked from the URL. Instead, users should use wildcards where > > >> this > > >> > functionality is necessary. To replace the method: prefix, you would > > >> instead > > >> > use "action:foo!input", then use a wildcard in your "foo" action > > >> name to > > >> support > > >> > the method call. In this way, the developer has to specifically > > allow > > >> this, > > >> > rather than the framework keeping that door (hole?) open. > > >> > > > >> > > >> I see, sorry, the action:foo!input thing didn't occur to me. Looking > > now > > >> in the webwork 2.2.2 source i see it's always been that way. > > >> > > >> dave > > >> > > >> > > >> > Don > > >> > > > >> > > > > >> > > dave > > >> > > > > >> > > > > >> > >> But, if no one is interested in working on the new API now, it > > >> should > > >> > >> not be framed as an impediment to a stable Struts 2.0 release. We > > >> > >> should judge each distribution on terms of what we have done, not > > on > > >> > >> what we would like to do. > > >> > >> > > >> > >> -Ted. > > >> > >> > > >> > >> > > >> > >> On 7/24/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: > > >> > >>> On 7/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > >> > >>>> -1 on changing the versioning scheme. > > >> > >>>> > > >> > >>>> But, I would be open to something like > > >> > >>>> > > >> > >>>> * Struts 2.0 == "WebWork transtional release" > > >> > >>>> * Struts 2.1 == "new API release" > > >> > >>>> * Struts 3.x == "phase 2 - the best of breed release" > > >> > >>> ...with pointers on what to consider if users should upgrade or > > >> not, > > >> > >>> and a clear explanation of what to expect in the near > > future. This > > >> > >>> could address Tim's initial concern (which I think is valid): > > >> > >>> > > >> > >>> "Users who don't keep completely up to date with the latest > > goings > > >> on will see > > >> > >>> this as the latest and greatest and start migrating to it, only > > to > > >> > >>> have a very rude surprise when large changes occur in 2.1, or a > > 3.0 > > >> > >>> arrives months later." > > >> > >>> > > >> > >>> Those three lines above, listing 2.0, 2.1 and 3.x, could be > > >> > >>> communicated on the front page, on a simple table. This would be > > >> > >>> similar to how Tomcat explains why they have three > > versions. Very > > >> > >>> straightforward and easy to digest. > > >> > >>> > > >> > >>> Hubert > > >> > >>> > > >> > >>> > > >> > >>>> IMHO, all the users, including ourselves, are served best when > > we > > >> > >>>> release early and release often. > > >> > >>>> > > >> > >>>> -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] > > >> > > >> > > > > > > > > > --------------------------------------------------------------------- > > 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]
