Rick Reumann wrote:
The approach isn't invalid as far as basic validation, but for security
I'd say it was not the best way to handle it. Let me ask you and Paul
this... how many times do you see Struts application's built where if
you are "Role A" you see X Y Z links but if you are "Role B" you see A B
C links. Maybe if you are a super Admin you can see X Y Z. Now maybe
link Y link calls /myAdminAction?someparam=1234 which is supposed to be
an admin only action. How many developers assume that "Well only admins
are going to see this page with that link so I don't have to check in
that Action if they have the correct role." I'm guessing a lot do, and
depending on the app (intranet vs external), I might opt to let it
slide. But the reality is there are plenty of times you can type in a
URL (if you remember the URL from some day when you were an Admin) and
you might be able to perform admin functions all from typing in URls.
You'd probably say, that isn't a secure system. Well the same thing I
see happening in this validate situation. If actual processing of the
URL without going through validate is that much of a security risk, then
I think you'd want to push that security check further back into the
system. Like I mentioned earlier, maybe down the line someone is going
to implement your front end in Flash or an Applet. Wouldn't you feel
safer knowing that back end components aren't going to let anything
really bad happen?
I don't disagree with any of that :) And yet...
Once thing I remember from years ago when I was a bit of a hacker (not
an especially good one, but still!) is that when you leave *any* hole,
the good hackers will find a way to exploit it. It's almost as
inevitable as taxes in this day and age. I agree, with all the
discussion we've all had on this, I don't view it as a "critical" flaw
either. But "non-critical" flaws have a nasty habit of becoming
critical ones when a good hacker takes a lool :)
Well, again, this is the kind of stuff I would never do in the validate
method. You might like to do it there, but going way back to when I was
first using Struts, it was always advised to NOT do this kind of
calculation in the validate method. Would you do credit card validation
there? I wouldn't. (Think of the mess that could happen in just this
case if your Action assumed it passed credit card validation in order to
ship a product and you bypassed the validate method by figuring out how
to add the canceled param ot the URL).
I think it's a very fine line between what is "basic" input validation
and what is business rules. I think your right, this is probably a case
where doing it in validate() wouldn't be the right answer because it
probably is a business rule... but it is at least debatable. Your
right, I wouldn't do credit card validation in validate() either, but
what about a simple checksum to see if the credit card is even in a
proper form? For instance, there is a formula to determine whether an
CC # is a Visa, Master Card, Discover, etc. Is this really a business
rule? You may argue it is, and that's not unreasonable, but I could
argue it's just a simple input validation, and I think that's just as valid.
I think unfortunately we've gone a little bit off-topic though, so we
should probably both stop :)
Because I don't think that's the place for this type of secure
validation. I've always taken the advice that the form's validate method
should ONLY check for proper structure of form entry elements - nothing
more.
Even though I said we should stop :) ... this is exactly my point from
above. The determination of what is a check for "proper structure" and
what is something more isn't clear-cut.
All the big wigs back when I was first learning Struts said don't
perform business-type checks in the validate method and that's what I
think you are attempting to. To me that type of security check should
ALWAYS be done deeper in the system and it's up to the backend/midtier
guys to make sure that always gets checked. You obviously disagree on
setting up the architecture that way which is fine. (Heck I could be way
off, I'm just a code monkey - nuttin' more:).
I don't disagree... but I don't think there is really a right and wrong
answer. If you ask my *opinion*, yes, any non-trivial validation should
be done at a lower level, absolutely. How you define non-trivial is the
question :)
I'm a code monkey too by the way, I just happen to be one that straddles
the coder/architect fence a whole lot. My job entails a pretty equal
dose of both these days.
You are correct, I probably shouldn't have brought up the manual
validate thing, since in this context it's not that relevant so I
apologize for that.
No need to apologize, not to me anyway :) It's not completely
unrelated... I'm just not sure it really helps solve the problem at
hand, not if we're trying to come up with a solution that will work for
everyone that is.
Hope you and Pual aren't taking this as I don't see your concern with
the issue you brought up. I do see your point. I wasn't aware myself of
the behavior brought up so thanks for bringing to my attention.
Not at all, I think this is valuable input into the discussion. Like I
said though, we *are* moving away from the core topic though, so we both
want to be cognizant of that.
Frank, do you have an Ajax validation tag for me to try out:) ?
No, but that's not a bad idea :) Then again, with what AjaxTags offers
now, it should be pretty trivial to tie in to Commons Validator and get
what you want. That might make for a really nice cookbook recipe :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
