Paul Benedict wrote:
Cancelable Actions (independently on the Action type: normal Actions,
DispatchActions) could
even implement a Cancelable interface with a cancel method.
Tamas, good one. I thought of this too but never mentioned it because
implementing interfaces
doesn't seem too cool/accepted in the Struts framework yet. (But that will
change in 1.3.) If I
add a Cancelable interface to my actions, then that could indicate to the
framework that these
actions deserve to be canceled; otherwise ignore the request parameter.
I didn't think it was a good idea at first, but now I don't think it's a
bad one.
The first question is whether backwards-compatibility *should* be
maintained... my usual stance is yes, it should be, and that was driving
my suggestions before.
Thinking about it more though, that's like Microsoft saying "yes, we
know this WMF flaw is a security issue, so we're going to provide a
mechanism to patch the hole, but it's going to be optional on the part
of developers... by default, the hole will continue to exist so that
backwards-compatibility is maintained". We'd all yell they are crazy if
they said that!
No, in this case I think it makes sense to break compatibility. The
question then becomes what is the least onerous way to do it so that
someone upgrading an existing app has as little to do as possible while
still being architecturally sound.
Well, the config parameters would probably be the easiest way, but the
interface seems more elegant architecturally. If I was maintaining an
app and I wanted to close this security hole with the least amount of
effort though, I would contend Paul's approach is probably better... If
we assume the new "cancelable" attribute on the <controller> defaults to
false, then I really just need to go through and add cancelable="true"
to any mappings that correspond to legitimately cancelable Actions,
which chances are isn't many. Contrast this to having to go through and
implement an interface and rebuild the app. Not a huge difference
perhaps, but enough (and don't forget that some shops have rather
onerous requirements before you could deploy the new build).
The interface isn't a bad suggestion though, after thinking about it a
bit. Either way :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
