Data Validation Functions

[Gene Wirchenko]

Hello:

I wish to validate data on a frontend. One such validation is
whether the input string is a number. I could parseInt() or
parseFloat(), but 1) I do not want to allow E-notation and 2) one form
of number that I want to check for is a dollar amount.

Is there a function (or more than one) that does this, or do I
have to roll my own?

If I do roll my own, one way to do it would be a regex. Is this
a good idea? What other alternatives are there?

I am looking for a general answer to use. I am not too concerned
with speed (unless a given way is way slower than others). General,
bulletproof methods are nicer than those not.

Assume that the parameter is a string. I do not care what
happens if the parameter is null, undefined, or data of another type.
(Unless I should. If so, why?)

Pointers to Websites, in case this has all been covered before,
are welcome.

Sincerely,

Gene Wirchenko

 

[Jukka K. Korpela]

I wish to validate data on a frontend. One such validation is
whether the input string is a number. I could parseInt() or
parseFloat(), but 1) I do not want to allow E-notation and 2) one form
of number that I want to check for is a dollar amount. [...]
If I do roll my own, one way to do it would be a regex. Is this
a good idea?

The advantage of using a regex is that you can then specify exactly the
format you accept. One problem with the approach is that it is difficult
to localize, if you ever need to consider different culture-specific
formats and different currencies. But I'm afraid there aren't many
options - studying the existing libraries and testing them is likely to
be more work than setting up a regexp.

Note that typically you need to check that there are no extra characters
- something that the standard routines don't check (they happily accept
'42foobar'). For example, to check that the input is a number without
E-part, you could match it against
/^[+-]?\d+(\.\d+)?$/
and if it passes, read it with parseFloat(). This would reject data like
..42 which might or might not be desirable; you need to decide what to
accept.

When reading a monetary amount, you should probably check for either no
decimal part or a decimal part with exactly two digits (though this is
in locale-specific too), since '$42.5' looks suspiciously like data error.

I am not too concerned
with speed (unless a given way is way slower than others).

Speed is irrelevant in matters like this. The computer has plenty of
cycles to spend when reading user input; it was different in the old
days of multiuser timesharing a few decades ago.

 

[Gene Wirchenko]

[snipped advice]

I wanted to make sure that I was on the right track. Thank you
for taking the time to confirm this.

Sincerely,

Gene Wirchenko

 

[Elegie]

On 04/11/2011 21:16, Gene Wirchenko wrote :

Hi,

I wish to validate data on a frontend.

This is fine, however you should know that some of your users may have
browsers with javascript being deactivated, or may override client-side
scripts with their own. As a result, you must make sure that data is
also validated on your server.

One such validation is
whether the input string is a number. I could parseInt() or
parseFloat(), but 1) I do not want to allow E-notation and 2) one form
of number that I want to check for is a dollar amount.

So you will also need to check for signs (+/-), thousand separators,
decimal separators, currency sign, optional zero for the integer part,
possible formatting spaces, and make sure you work in a decimal base
(javascript allowing numbers to be expressed in octal, decimal and
hexadecimal bases).

Also, javascript doesn't have decimal arithmetic, so if you do
calculations on the client, you'll have to round results.

Is there a function (or more than one) that does this, or do I
have to roll my own?

There is no native function to do this, but such requirement is pretty
basic, and looking up the web a bit should give you profusion of
data-checking functions. You'll simply have to make sure they pass your
tests, and if necessary adjust them to your needs.

Also try and search John Stockton's website, you should find some useful
functions there:

If I do roll my own, one way to do it would be a regex. Is this
a good idea? What other alternatives are there?

Sure, using a regexp would be perfectly fine (and the preferred way). If
you do not want to use a regexp, then you may apply standard string
manipulations methods (performing char analysis for instance).

Assume that the parameter is a string. I do not care what
happens if the parameter is null, undefined, or data of another type.
(Unless I should. If so, why?)

Well, you don't want to get some null pointer exception, right?

Also, you should be aware that javascript has loose typing, and
therefore has native type conversion routines which may look strange to
the newcomer. It could be interesting for you to check those.

Note that your input will likely be read from form controls, and will
therefore always be a string (unless you use third-parties libraries
which fancy type-converting user inputs). You're therefore unlikely to
meet type issues here. Again, your test suite shall protect you.

<snip>

Regards,
Elegie.

 

[Denis McMahon]

I wish to validate data on a frontend.

Make sure that you *also* validate it on the backend.

Any front end data validation can probably be bypassed by a hostile user,
and can not be relied on by the server application that receives such
"validated" input. The only use for frontend (client side) validation is
to catch input errors and allow the user to correct them, not to prevent
the backend receiving invalid or even malicious input.

Rgds

Denis McMahon

 

[Gene Wirchenko]

Make sure that you *also* validate it on the backend.

This point seems to stick with people. Are there any spectacular

Any front end data validation can probably be bypassed by a hostile user,

...I have a NoScript and I am not afraid to use it. I normally
run with JavaScript disabled.

and can not be relied on by the server application that receives such
"validated" input. The only use for frontend (client side) validation is
to catch input errors and allow the user to correct them, not to prevent
the backend receiving invalid or even malicious input.

I will probably be going overboard on the frontend checking, but
I will not forget the backend.

Sincerely,

Gene Wirchenko

 

[Elegie]

This point seems to stick with people. Are there any spectacular
stories to tell?

<snip>

Maybe not spectacular, by all too frequent stories. Most beginners think
that doing the validation in the client-side script suffices, and many
will even try to defend this approach by stating that their target
environment is controlled.

You started participating in this group by stating that you were a
beginner (even though you had previous experience with other languages
and platforms), wanted to be informed about known pitfalls, so it seems
reasonable for regular posters to make the assumption that you actually
are a beginner, want to be informed about known pitfalls, and
consequently to provide you with appropriate advice and warnings

 

[Gene Wirchenko]

<snip>

Maybe not spectacular, by all too frequent stories. Most beginners think
that doing the validation in the client-side script suffices, and many
will even try to defend this approach by stating that their target
environment is controlled.

Oh, do I know that! I got my degree recently after many years in
the industry. Some of my classmates had very weird ideas about how
computers and the industry work.

You started participating in this group by stating that you were a
beginner (even though you had previous experience with other languages
and platforms), wanted to be informed about known pitfalls, so it seems
reasonable for regular posters to make the assumption that you actually
are a beginner, want to be informed about known pitfalls, and
consequently to provide you with appropriate advice and warnings

*** You are doing exactly what I want. Thank you. ***

At some point, I am going to have something that works. I hope
then it will get the evil eyeball from people. ("Oh, you shouldn't
have.") e.g. I found out today that, rather than using escape(), I
should use encodeURIComponent(). At this point, I would not have
figured that out myself.

Many corrections are easy once one knows that a correction needs
to be made.

Sincerely,

Gene Wirchenko

 

[Tim Streater]

At some point, I am going to have something that works. I hope
then it will get the evil eyeball from people. ("Oh, you shouldn't
have.") e.g. I found out today that, rather than using escape(), I
should use encodeURIComponent(). At this point, I would not have
figured that out myself.

That, I find, is where a book or two comes in handy. For JavaScript, I
have Danny Goodman's "JavaScript Bible" and Flanagan's "JavaScript the
definitive guide". But I'd suggest you look on e.g. Amazon to "look
inside" these or others to find what is to your taste. Doubtless some
here will question my choice of tomes but such opinions are by and large
irrelevant. The advantage of the books is that they will comment on
whether one function is a better choice than another, and why, and then
you can make your own mind up.