Not going to rehash the issues including the issues in the new thread
started by Michael and the summary brought up by Laurie in that thread
(and yes Franks this thread is nested, somehow michael's message started
with a new messageId which breaks into a new top level thread for those
clients that base a thread on messageID - which they should:)
Lastly, I never run into these problems because
1) I never liked the cancel button and its behavior. It's 'too behind
the scenes' for me in the whole setting of an isCanceled param and all
that jazz. To me it always made since to handle cancel with a true
submit of the form and set the dispatch param to cancel or if using a
Michael/McGrady/or Mapipng type of dispatch some other key. Then you
simply handle it like any other Action. It's clean and easy to
understand and you never have to worry about these under-the-cover things.
2) Use a DispatchAction. I really don't get why some of you are against
them:) Do you make separate "DaoForCreate" and "DaoForUpdate" objects?
My guess is you have one Dao that handles CRUD for a particular type of
concern. To me it's just annoying having separate actions for related
events, and it makes it more difficult when you want to do things
related to these events. To each his/her own I guess:)
3) Call the validation framework manually. I can give several reasons
why this is a good idea and saves the developer a lot of headaches, but
I've been over it before (happy to readdress if someone wants me to:).
It's not much more code to write and actually simplifies things (very
easy to see what's going on by simply looking at your Action class).
Anyway, that's my advice for anyone having trouble with Cancel issues.
I do now see though the issue that Paul brings up and that Frank
clarified and Laurie clarified further in the summary, although I still
don't see it as "high" security risk since I would never rely on the
validate method to handle something that could be that much of a risk. A
bit more on that below in reference to Frank's example below...
Frank W. Zammetti wrote:
Let's say my bank's web site allows me to have a primary user account,
and I can link to this account all my checking accounts and savings
account to see them all in one "dashboard" display. I have to fill out
a form to have an account added. The form has account number on it.
Let's say one of the validations is to be sure the checksum of the
entered account number matches one that would only be valid for me. It's
a relatively simple math check, so it's done in validate() because
really we're checking that the entered value is "valid".
Now, the Action behind it calls some DAO to add the account for me. But,
it reasonably assumes that the data it gets in the form is valid. So, if
validate() is not executed, I could conceivably enter an account number
that isn't mine and have it attached to my user account and see its
details.
See I think that's a poor design. Why would you rely on a Struts
validate method to handle that? For a financial application wouldn't you
always be checking the account number vs the supposed user in Session
scope somewhere in a non-Struts layer? The whole idea of component stuff
is if later on you coded the front end in swing or flash that you would
still have the security stuff ensured on the backend. I don't think
letting a framework handle this type of security check is a good idea.
> I doubt too many people would say it's a
"wrong" approach (we could of course argue architecture, that's always
the case, but nothing stands out as patently "wrong" to me about this
design).
I'd say it's wrong from the standpoint that the backend should be
checking this and throwing an exception. This whole thread is a perfect
example why:) - don't assume the front-end is making things secure.
Maybe later on you needed a flash front end they have other security
concerns, at least if you code the backend part to make it's security
check things are much better. (Granted someone might find a way to spoof
a logged in user, but that's not what we are talking about here).
I think the problem here though is that this is a fairly subtle thing,
and something that could possibly be exploited in such a way that the
request looks legitimate, and in fact is, as far as the filters and
security checks go, but are not in terms of the logic of the application.
Agreed that it probably should be handled better. My only argument is
that I think it's level of a 'security' risk is pretty low, unless you
are coding for security in your validate method, which I don't think is
a good idea.
I don't want to blow this out of proportion... I think the way most
people architect their solutions, this probably wouldn't be a problem
for most people.
Agreed.
But, even if we all agreed that it wasn't a security problem per se, it
just logically does not make sense as far as I can see... if Struts is
going to populate the form, I can't think of a good reason it wouldn't
call validate() too, like any other request, just because the action was
canceled.
Well the problem is the user should be able to cancel and leave the form
without having to fill out everything. You certainly don't want it
validated simply to 'cancel' and leave the form. Why would you want to
require the user to fully completely a form that he wants to cancel out of?
I agree though that behavior should be looked into, but I'm not sure of
a good answer. All of these problems stem from Struts' lame-o validation
procedure - the weakest part of Struts imo (all the other newer
frameworks handle this much better). Bottom line is not setting
validate='true' is the best thing a user can do:)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
