Rick Reumann wrote:
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:)
But, I believe Paul said this issue affects DispatchAction too... am I
right Paul? Perhaps you could explain that part again? I'd rather not
explain incorrectly if this is true.
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).
You may be 100% right, but it's not especially relevant to this... I'm
sure you wouldn't say the solution is for everyone who is using
automatic validation now to rewrite their apps, are you? :)
Anyway, that's my advice for anyone having trouble with Cancel issues.
Oops, I guess you are :) I kind of assume you mean this with the
qualification "going forward". Many people use automatic validation and
frankly love it, I doubt they would be in a rush to redo their existing
apps.
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?
I think your getting hung up on the design of the thought experiment
rather than the underlying concept it's trying to demonstrate... yes,
there are almost certainly better ways to implement such a function, but
that doesn't mean what I outlined is an invalid approach...
I can tell you from experience, I once wrote an app where you entered an
account number and we had a validation to tell if it was valid based on
nothing else but the account number. It's 100% an input validation...
the user entered it, we need to know if it's valid, and we can determine
that just by running it through some calculations.
Now, what if there was some component to that validation that included
the identity of the user, like in the theoretical app? Why would it
suddenly not be a good idea to do that as part of input validation?
Since I get request in validate(), I can get the info I need from
session as you suggest, and therefore I can do everything I need to in
validate(). Why would I incur the overhead of executing the Action,
executing whatever business helper I have, maybe more, when I can do it
all *before* any of that is hit?
Again, I don't want to start debating whether your approach in terms of
manually calling validate() is better or not because it doesn't
ultimately matter in this context... many people don't do that, and
expect that the framework will do it (which isn't completely
unreasonable), and that's when this comes into play.
> 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.
That's a pretty good argument :)
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).
You always run into questions about where the different tiers begin and
end though. Besides, should an app throw an exception if I enter an
invalid account number? If it does, you have one very unhappy customer!
It should handle it gracefully, relatively speaking at least, and a
big part of the point of any framework is to facilitate that sort of
thing. If I have to do it all myself anyway, why am I using Struts in
the first place? :)
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 wonder if your assessment might be a bit skewed by the approach you
use, which does seem to insulate you from this?
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, I don't think I had really thought that scenario out as well as
I could have when I originally wrote that paragraph.
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:)
...but it won't help a user who needs to remediate an existing app :)
--
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]
