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]
