At 4:51 PM -0500 1/23/06, Frank W. Zammetti wrote:
> The proposed solution requires that the person intentionally using
this feature make one further indication in the struts-config file,
...snip...
> the "cancel" parameter for any action (path) that accepts it, leaving
all other actions invulnerable to the "attack".
This is where I'm not understanding... are you saying that if the
arbitrary mapping parameter MAPPING_PARAMETER is *not* present, then
validate would *never* be bypassed, or are you saying things would
function as they do today except that you could name the request parameter
to interrogate per-mapping? If it's the former then I get it and think
that would work, if it's the later then I'm still missing something :)
(and if it's something else entirely, that speaks for itself! LOL)
So, in fact, you are getting it, and I think we should drop the
configurable parameter name thing anyway, since it would be too much
more work to make that work with the <html:cancel> tag, and I haven't
seen enough indication that anyone really wants to use this
"cancelled" feature that much anyway.
I do think this is a case where backwards-compatibility shouldn't be a
primary concern by the way... we're talking about closing a potential
security hole, however big one deems it to be, and if that requires an
incompatible solution, I think that's acceptable. It's not an enhancement
after all, not primarily at least.
At 4:54 PM -0500 1/23/06, Rick Reumann wrote:
On 1/23/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 3:37 PM -0500 1/23/06, Frank W. Zammetti wrote:
> The proposed solution requires that the person intentionally using
this feature make one further indication in the struts-config file,
...snip...
> the "cancel" parameter for any action (path) that accepts it, leaving
all other actions invulnerable to the "attack".
I like that solution but it's not backwards compatible which I thought
was what we were trying to make happen as well as fix the problem. If
someone updates their code with these latest jars they will have to
find all the spots in the config where they want to allow a cancel to
take place. I'm not saying that's a bad thing, it's just that if the
code isn't going to be backwards compatible we might have other
options to improve upon the situation.
No, I don't really care about compatibility if we're going to bother
to fix this, because as noted I don't think a lot of people use
"cancel" but I do think a lot of people use "validate='true'"
I remember now why I didn't really like the way the cancel mechanism
initially was designed. It's ok for regular actions since you only
have one method and you can easily check for 'isCanceled' and do what
you need to do. For DispatchActions though this was a bit of a pain
unless you provided a base class with an execute method to catch the
cancel. If you didn't use a base class you could potentially be
entering several dispatch methods from the same form (imagine a case
where you might have an updateFooBar and insertFooBar dispatch
method). In both methods you now have to test for 'isCancelled'. It
just never felt right to me. To me at least it always seemed better to
just go to a "cancelled" method if that's what I want to do vs having
to check everywhere for "isCancelled."
If you were using a dispatch action, aren't there decent odds that
you'd need to dispatch cancellations too?
I guess it is easier to go through and fix your actionMappings vs
moving some "isCancelled" block in your Action into a "canceled"
method, so the solution proposed is ok. I just think you might get
more people using html:cancel if it had the slightly different
behavior of executing a cancel method. I guess that is too radical a
change though:)
You think? Can anyone even describe use cases where it's valuable to
have some cancel process happen? I mean realistic use cases, not
just exercises.
Anyway, my main goal in choosing a solution is one that is lowest
impact to users and to the code architecture, unless we have more
positive use cases for improving the "cancel" feature -- so if you
think more people would actually use it, let's understand how/why,
and from there we can figure out what the right route is (and what
facets of the solution are for which version of Struts.)
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
