Re: DefaultActionMapper compatablity switch

["Frank W. Zammetti" <fz...@omnytex.com>]

Potentially simple solution: a config switch to turn this functionality 
on (the ability to specify method in the URL).  It'd be off by default. 
  That way everyone can be happy... security "hole" closed, but easy to 
activate for those who want it.

Frank

Don Brown 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 <ds...@berndtgroup.net> 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 <hr...@gmail.com> wrote:
>>> > >>> On 7/24/06, Ted Husted <hu...@apache.org> 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: dev-unsubscribe@struts.apache.org
>>> > >>> For additional commands, e-mail: dev-help@struts.apache.org
>>> > >>>
>>> > >>>
>>> > >>
>>> > >
>>> > >
>>> > > 
>>> ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> > > For additional commands, e-mail: dev-help@struts.apache.org
>>> > >
>>> > >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> > For additional commands, e-mail: dev-help@struts.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 
> 
> 

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: DefaultActionMapper compatablity switch

[Ted Husted <hu...@apache.org>]

On 7/24/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Potentially simple solution: a config switch to turn this functionality
> on (the ability to specify method in the URL).  It'd be off by default.
>   That way everyone can be happy... security "hole" closed, but easy to
> activate for those who want it.

Yes, we have a webwork switch that controls the alias behavior, and
potentially others.

* http://www.twdata.org/backups/WW/release-notes-200.html#ReleaseNotes2.0.0-Newpropertysettings

I don't think we need to finely grade the switch.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org