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]

Reply via email to