Tom Eugelink wrote:
>
> I have to totally agree here. Only the server is a trustworthy node in the
> process. One cannot assume that javascript has correctly validated the data.
> Any validation done on the client should be considered an extra service, not
> a replacement for serverside validations.
>
In my case, I do both client-side (to the degree possible) and server-side
authentication. Why?
* Client side validation improves the user experience by catching things
quickly, before the submit-error-fix-resubmit loop happens. Of course,
you cannot catch everything, and not every user will have JavaScript
enabled.
* Server-side validation should be considered imperative. How do YOU
know the client has JavaScript turned on? How do YOU know that the
client submitting this request is even a browser? It might be a customer's
application, where you're using the web application to create a B2B
integration link.
If your server application lets any corrupted data get stored in the database, it
is *always* your server application's fault -- no excuses accepted. Therefore,
"paranoid" checking of everything in the server is the self defense behavior I
always choose.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
