If everyone used dispatch-type Actions, I would disagree because then it
would just be a matter of providing a cancel() method and making sure
that got called. But, since not everyone does (including me whenever I
can avoid it), that's not the end of the story.
Interestingly, the doc for the cancel tag *does* say that validate()
won't be called and that the Action will be called normally. I never
noticed this before. So, at least no one can claim this behavior isn't
documented :)
There's really two problems here... one revolves around how this feature
maybe should have been designed in the first place. Tamas may be right
in that regard. The second problem though is you have apps built with
it the way it is now, for better or worse, and breaking those to close
this hole isn't really the best idea.
With that in mind, I'm thinking something along the lines of Paul's
original suggestion may in fact be the best... add a "cancelable"
attribute to the <action> element in config. Default to true. When set
to false and the Action is called, that's the "hacker" case we want to
avoid... maybe throw an IllegalStateException? Maybe look for an
"illegalCancel" forward? Not sure what's best, but the point is to
avoid calling execute() in that case. This would maintain the existing
behavior by default too.
No, actually, better yet, as Paul suggested, add cancelable to the
<processor> element as well. I think you really need it to be on both
<processor> and <action> though... set it to false on the <processor> to
globally close the security hole, then set it to true on the <action>'s
where it applies.
Frank
Adam Hardy wrote:
Tamas Szabo on 22/01/06 07:30, wrote:
There is a legitimate case: when an form can be cancelled, you do
want to skip client-side and server-side validation. That's just
fine because in these case you do want to call the cancelled() method
from DispatchAction, dump out any state you collected, and
go to the appropriate forward.
In my oppinion it isn't ahndled correctly and I don't think that it
should be solved by configuration script. If the user presses Cancel
then the processing should go on another path. It doesn't make sense
to populate and to validate if cancel was pressed.
I agree. I _do_ use the cancel button on many forms and this is what I
implement - if Struts did it itself, it would save me time and effort.
Plus it would be safer on other actions where I don't use the cancel
button.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
