Best way to validate a form's input on submit?

magellan · Sep 21, 2014

I need to verify the input fields on a form are all filled out. I was thinking of creating a javascript onclick event handler for the submit button, then using javascript to make sure all input fields don't have their default values and aren't empty/null. If the input fields aren't all filled out I was just planning on using an alert box to report that all input fields need to be filled out before the form is submitted. If anyone has any tips, pointers or better ways of doing this I'd like to hear them.

pcgamer4life · Sep 21, 2014

You've got the basic idea correct. Just write a form validation function and call it from your submit button's onsubmit property. You could validate from your button's onclick event as well, but generally that's not a best practice. Onclick won't fire if you tab to the control and hit space, or hit enter to submit the form.

ratbuddy · Sep 21, 2014

Client side validation is OK if you want to reduce load on your server, but you should never ever rely on it. Users can easily disable javascript or use other programs to submit any input they want, and if your server doesn't validate inputs before using them, you are in trouble. Try googling 'PHP input validation' or ASP or whatever you are using on the server.

pcgamer4life · Sep 22, 2014

A very valid point. For making sure that all form fields are filled out, Javascript validation will be fine, but you'll want to check the integrity of your inputs on the backend as well.

su root · Sep 26, 2014

Typically what I do is have a "change" or "onblur" event that checks the form, and if the data is wrong, it adds a "validation-fail" class to that input element. That CSS class would then border it in red, tint the background light red and put an exclaimation mark icon next to it. If it validates correctly, it deletes the class.

I usually have a few different kinds of validations... onblur="validateNumber(this);" onblur="validateIP(this);" onblur="validateString(this);" etc.

But as ratbuddy says, definitely re-do the validation on the server side to make sure you get what you are looking for, no more, no less.

magellan · Sep 27, 2014

I can see server side validation as a must do (especially if the values are going into a DB), but what do you
do if you do find invalid input on the server side? The user's browser has already sent the data to the server.

pcgamer4life · Sep 27, 2014

It really depends on how much effort you want to put into it, and the experience you want the user to have. The easiest solution would be to just redirect them to some non-descriptive error page and have them try again. A more elegant solution would be to save their form data in a session variable, redirect them back to the form, and re-populate the form with the data they originally input, and highlight the data that was invalid.

magellan · Sep 27, 2014

How do you do client side form validation if the user has turned off javascript in their browser? CGI scripts?

magellan · Sep 27, 2014

Thankfully the data I'm validating isn't of a mission critical or financial nature. I don't think a hacker would get anything of value out of hacking this form or DB, it's also on an internal intranet and inaccessible from the outside world. It's basically a simple held desk support ticket system.

su root · Sep 27, 2014

magellan said:
I can see server side validation as a must do (especially if the values are going into a DB), but what do you
do if you do find invalid input on the server side? The user's browser has already sent the data to the server.

Send them back to the same form, filled out with what they already entered, plus an error message.

It doesn't matter whether it's finanical, mission critical, internal or for your own use, get in the habbit of always validating input on server side. Client side is an optional bonus to save time for the users. Things that aren't mission critical have a habit of becoming mission critical, things that are internal only have a habit of becoming widely used internally, or extended to partners. Server-side input validation isn't too much extra code or time, but saves so many headaches later.

ratbuddy · Sep 27, 2014

magellan said:
How do you do client side form validation if the user has turned off javascript in their browser? CGI scripts?

Quite simply, you don't trust clientside anything. Ever. I mean it.

Er, CGI is not a clientside technology btw. It's a way of running a program on the server using input from a browser request.

johan851 · Sep 27, 2014

ratbuddy said:
Client side validation is OK if you want to reduce load on your server, but you should never ever rely on it. Users can easily disable javascript or use other programs to submit any input they want, and if your server doesn't validate inputs before using them, you are in trouble. Try googling 'PHP input validation' or ASP or whatever you are using on the server.

Agreed. Javascript validation is convenient and provides quick feedback to the user, but the real validation should occur on the server.

magellan · Oct 23, 2014

Why can't you use client-side javascript form validation? I can do all the same kind of tests for invalid input w/javascript that I can do
with PHP. Why do the same kind of input validation twice if you're not using GET values? Is it a security issue w/javascript?
It's an odd idea to have to re-validate the form input on the server side that I just validated with javascript on the client side.

su root · Oct 23, 2014

magellan said:
Why can't you use client-side javascript form validation? I can do all the same kind of tests for invalid input w/javascript that I can do
with PHP. Why do the same kind of input validation twice if you're not using GET values? Is it a security issue w/javascript?
It's an odd idea to have to re-validate the form input on the server side that I just validated with javascript on the client side.

Two different purposes. In javascript, you are trying to provide immediate feedback to the user, and save them a page load or two, if what they entered is not acceptable.

On the server side, the validation is there to protect the server against injection attacks (SQL Injection, Command Injection, SMTP Header Injection, etc). The secondary reason is to ensure that the information you receive is actually complete (typically the same as javascript, possibly with more complete testing) -- it is not much effort for an attacker to disable or manipulate the javascript and submit an incomplete form, or form values that attempt an exploit.

ratbuddy · Oct 23, 2014

magellan said:
Why can't you use client-side javascript form validation? I can do all the same kind of tests for invalid input w/javascript that I can do
with PHP. Why do the same kind of input validation twice if you're not using GET values? Is it a security issue w/javascript?
It's an odd idea to have to re-validate the form input on the server side that I just validated with javascript on the client side.

If the user disabled or modified your javascript, you didn't actually validate anything. Trusting any user input is monumentally foolish.

petteyg359 · Oct 23, 2014

Terminology nitpick: Validity can only be determined on the server. Client-side Javascript can only perform conformance checking, not validation. Call it conformation if you need a "-tion"

magellan · Oct 24, 2014

ratbuddy said:
If the user disabled or modified your javascript, you didn't actually validate anything. Trusting any user input is monumentally foolish.

My project manager may well decide server side validation isn't worth the trouble for this corporate intranet web portal, a hacker wouldn't get much out of compromising it, as there is no data of a confidential nature manipulated by this app and the app itself as well as the virtual server it runs on are not mission critical in any way. If he wants to pay for it though, I'm game.

su root · Oct 24, 2014

magellan said:
My project manager may well decide server side validation isn't worth the trouble for this corporate intranet web portal, a hacker wouldn't get much out of compromising it, as there is no data of a confidential nature manipulated by this app and the app itself as well as the virtual server it runs on are not mission critical in any way. If he wants to pay for it though, I'm game.

The better approach is to always code securely. Yes, it takes more time and effort, but it's a good habit to get into, and will make your applications last a lot longer.

If the first time someone tries to put a quote into an input box (such as a last name with an apostrophe), it fails with a bunch of errors, it will be perceived as "poor quality of work", and they won't make the connection to "we didn't pay for security".

Also, you think the company's Intranet website is so small a target for hackers that it isn't worth the effort? I can tell you that it will always be a target, as there's always a reason why any internal website is not publicly accessible. And, it will become a bigger and bigger target over time, as people add more and more company-private information (not to mention things like watering hole attacks).

pcgamer4life · Oct 24, 2014

su root said:
Also, you think the company's Intranet website is so small a target for hackers that it isn't worth the effort? I can tell you that it will always be a target, as there's always a reason why any internal website is not publicly accessible. And, it will become a bigger and bigger target over time, as people add more and more company-private information (not to mention things like watering hole attacks).

I can vouch for this. I inherited an intranet site at work that I am now the sole developer on. Granted, it's ASP.NET so all validation is done on the server side anyway, but I can absolutely say that the scope will grow over time, and if you don't do it correctly now, it will eventually catch up with you. Up until recently, the site was storing passwords in plain text in the membership provider, even though it was generating and storing salts for every user by default. All the original developer would have had to do was flip a bit in the config file from the beginning and it would have been fine. Instead, I have to re-engineer it and the 3rd party process we use to synchronize our application passwords with as little visibility as possible to prevent getting dinged on an audit.

magellan · Oct 24, 2014

su root said:
The better approach is to always code securely. Yes, it takes more time and effort, but it's a good habit to get into, and will make your applications last a lot longer.

If the first time someone tries to put a quote into an input box (such as a last name with an apostrophe), it fails with a bunch of errors, it will be perceived as "poor quality of work", and they won't make the connection to "we didn't pay for security".

Also, you think the company's Intranet website is so small a target for hackers that it isn't worth the effort? I can tell you that it will always be a target, as there's always a reason why any internal website is not publicly accessible. And, it will become a bigger and bigger target over time, as people add more and more company-private information (not to mention things like watering hole attacks).

Who's going to be hacking it anyway? Employees? Contractors? People who will be fired for doing so? They're the only ones w/access to the corporate intranet.

The Oracle documentation for oci_bind_by_name indicates the following:
"Binding reduces SQL Injection concerns because the data associated with a bind variable is never treated as part of the SQL statement. It does not need quoting or escaping."

I see your points all too clearly though.

Best way to validate a form's input on submit?

Member

Member

Member

Member

Senior Member, --, I teach people how to read your

Member

Member

Member

Member

Senior Member, --, I teach people how to read your

Member

Insatiably Malcontent, Senior Member

Member

Senior Member, --, I teach people how to read your

Member

Likes Popcorn

Member

Senior Member, --, I teach people how to read your

Member

Member

Similar threads