Frank W. Zammetti wrote:
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? :)
No you are right there. I know people like the automatic validation
stuff:) and I do see the problem Paul brought up and I do see how it
could affect dispatch actions also if someone typed in the URL with
canceled. But I don't see this as a 'big' security concern was my only
point (More in a bit on that)...
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...
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 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.
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).
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?
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. 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:).
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.
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. I'm only now harping on the idea that the issue
shouldn't be that big of a security concern since I don't think the
Struts designers ever envisioned doing hard core security checks in the
validate method. Think of how scary it would be if by accident someone
made a small change from validate="true" to validate="false" and the
release went out and you were doing major security checks in your
validate method.
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? :)
You can handle the exception very gracefully. To the user it will look
exactly like a typical form validation error. You can either user a
declarative exception for that mapping or handle it directly in your
Action call. Point is it, it will still be just as graceful to the user.
(The only time it's not 'perfectly' graceful is if say you have a bunch
of text inputs and that account number. Maybe you are using the
automatic validation to check that a number field was entered correctly.
What could happen is the user submits the form once and has to fix some
formatting errors, then submit again only to get another error about the
account number. To me, that's only a small price to pay. If it becomes
super serious you can always add the extra check (which just be some
utility method) in the validate method, but yes, then you are doing the
check twice - but remember this is an application where security is a
concern so to me that's not a big deal - what's it going to cost you an
extra few milliseconds for the extra check on the backend to make ensure
security?)
I wonder if your assessment might be a bit skewed by the approach you
use, which does seem to insulate you from this?
Well sure I do think my approach would insulate you a bit better, but
even using my approach (validate manually, etc), I still wouldn't be
putting the security checks in the validate method (at least not 'just'
there).
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 :)
I think the answer to existing apps is to just push the security up a
layer. Yea I know the tiers get blended a bit, but in a typical app my
structure might look like...
AcionForm --- Action
Action makes calls to a "Service" class
The Service class has NO ties to Struts jars
So it can be reused and called by any front end
Service ---> calls Daos for CRUD
So I'd simply do a check in the Service class..
//FooBarService
public void updateFooBar( User user, FooBar fooBar) {
boolean ok = SomeOtherClass.canFooBarDoThisUpdate(user, fooBar);
if ( ok ) { dao.update( foobar ); }
else {
throw Exception that will be caught by Front end (Action in case
of Struts)
}
The benefit to this approach again is maybe you have a JSF lover like
Dakota Jack wanting to port your app over to JSF. Well as a
backend/midtier guy you can be sure that at least the security contracts
are met from your side of things. Sure fooBar above might have an
invalid date if the front end guys didn't check for that, but at least
it won't be a security violation.
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.
Frank, do you have an Ajax validation tag for me to try out:) ?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
