[EMAIL PROTECTED] wrote:
>>I wouldn't recommend that. You should *always* do server side input
>>validation. The reason is very simple, never trust clients :)
>Not sure why you would "not trust clients"? They arent the ones validating
>it..(unless you mean the browser), the JavaScript code is.
By client I mean client in the context of client-server. The client could
be a web browser, applet, application, PDA , etc ...
>>It would be very easy for a person to see GET (or even POST) parameters
>passed to your JSP or servlet, and then fake your "CRC".
>It would be the same even if they dont validate it..only the end result may
>be the server spitting back some values in fields that were not originally
>entered..thus the only benefit I see with that is that the client would
>notice these and wonder how that happened. With a SSL, I dont worry about
>that. At least, on our site, the pros outweigh the cons. It makes more
>sense to use client-side in my opinion because its an immediate display
>when an entry is errored. Like I said before (to someone) I personally dont
>like entering alot of form info only to find one field messed up and have
>to reenter it. Alot of sites actually wipe out most of the fields (required
>fields) and make you reenter it all. With client-side its done immediately.
>If anyone is so worried, make it SSL.
SSL has nothing to do with this. I'm not talking about authenticating users
(that's another topic), what I'm saying is that it's great to have
client side validation but that in itself should not be the only place
you check for valid values. You should *always* check in your server too !
>>o Code in client script might have errors that permit invalid data.
>Those errors should be tested and caught by QA team or the developer
>writing the script.
Hehe ... guess you're the only one with a perfect QA departement !!! :)
>>o Business Logic should be kept in the server.
>Agreed.
Glad to hear that.
>>o What happens if a user is using a cached version of your validation code ?
>dont quite no why this is a problem? The only thing being wrong here is if
>the page with the form data is cached. We use the META tags (and soon
>SetHeader calls) to make sure no dynamic page is cached. Also, I use a
>2-frame setup, where the javascript code is in a hidden frame. This gives
>me the ability to "cache" all the images on the site but allow the dynamic
>pages not to cache so they always go to the server to be redisplayed. We
>had a situation where I wasnt doing this before and every page reloaded all
>the images as well which took some time.
The users browser might ignore the META tags. This can be a bug or a feature,
but it's perfectly doable. I've read over and over people having problems from
preventing caching in popular browsers like IE 5.0, etc ...
>>o Application State might have changed between the time the server & client
>> complete their transaction.
>Not sure I understand why this would have anything to do with form validation?
An example;
Please choose what you want to eat { apple, banana, orange }(this is a combobox)
Then, while the user is reading this webpage, somebody on the backend
deletes the choice of banana (they don't sell well).
A form of client side validation is having thing like comboboxes (or choice
menus) because they don't let the user enter the wrong choice. However,
in the case, the choices changed. If I didn't check on the server , I would
enter invalid data, since bananas are don't exist on my server anymore :)
There are more examples, but I hope this illustrates what I mean ...
>Is there any reason why data your worried about cant be sent via SSL? I
>realize its a bit slower..but if safety and validation is what your after,
>thats the best way to go.
SSL is nice, but not always available. However, I think the purpose of
SSL is to protect transactions, not to validate nor guarantee data is valid.
I could always invoke a script
https://foobar.com/servlet/UserManagerServlet?action=create&username=INVALID+USER+NAME+12232323&password=INVALID+USER+PASSWORD+232323
If blank spaces and/or numbers are not allowed in my UserManagerServlet
and I trust the invoker of this script, I'm hosed, and I just entered bad
data for not checking again in my servlet code.
Also, remember that things like servlets (and JSPs too in some cases) can
have many entry points, like different webpages , different client applications , etc
invoking them, and sometimes it's not possible to keep the same validation code
acrooss that spectrum.
...
Augusto
----------
Message To Spammers -- Game Over! Get spam-free email at http://www.MsgTo.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
