Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #8007 > unrolled thread

Data Validation Functions

Back to article view | Back to comp.lang.javascript

Contents

  Data Validation Functions Gene Wirchenko <genew@ocis.net> - 2011-11-04 13:16 -0700
    Re: Data Validation Functions "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-11-04 22:42 +0200
      Re: Data Validation Functions Gene Wirchenko <genew@ocis.net> - 2011-11-04 14:04 -0700
    Re: Data Validation Functions Elegie <elegie@anonymous.invalid> - 2011-11-04 22:06 +0100
    Re: Data Validation Functions Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-04 21:45 +0000
      Re: Data Validation Functions Gene Wirchenko <genew@ocis.net> - 2011-11-04 15:11 -0700
        Re: Data Validation Functions Elegie <elegie@anonymous.invalid> - 2011-11-04 23:40 +0100
          Re: Data Validation Functions Gene Wirchenko <genew@ocis.net> - 2011-11-04 16:11 -0700
            Re: Data Validation Functions Tim Streater <timstreater@greenbee.net> - 2011-11-04 23:26 +0000

#8007 — Data Validation Functions

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

[toc] | [next] | [standalone]

#8010

11/4/2011 10:16 PM, Gene Wirchenko wrote:

>       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. :-)

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#8013

On Fri, 04 Nov 2011 22:42:38 +0200, "Jukka K. Korpela"
<jkorpela@cs.tut.fi> wrote:

>11/4/2011 10:16 PM, Gene Wirchenko wrote:
>
>>       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.

[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

[toc] | [prev] | [next] | [standalone]

#8014

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:

<URL:http://www.merlyn.demon.co.uk/js-valid.htm>

>       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).

<snip>

>       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.

[toc] | [prev] | [next] | [standalone]

#8017

On Fri, 04 Nov 2011 13:16:06 -0700, Gene Wirchenko wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#8021

On 04 Nov 2011 21:45:08 GMT, Denis McMahon <denismfmcmahon@gmail.com>
wrote:

>On Fri, 04 Nov 2011 13:16:06 -0700, Gene Wirchenko wrote:
>
>> I wish to validate data on a frontend.
>
>Make sure that you *also* validate it on the backend.

     This point seems to stick with people.  Are there any spectacular
stories to tell?  <nudge, nudge>  I *am* keeping it in mind.  That is
easy since...

>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

[toc] | [prev] | [next] | [standalone]

#8023

On 04/11/2011 23:11, Gene Wirchenko wrote :

>> Make sure that you *also* validate it on the backend.
>
>       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 :)

[toc] | [prev] | [next] | [standalone]

#8024

On Fri, 04 Nov 2011 23:40:12 +0100, Elegie <elegie@anonymous.invalid>
wrote:

>On 04/11/2011 23:11, Gene Wirchenko wrote :
>
>>> Make sure that you *also* validate it on the backend.
>>
>>       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.

     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

     

[toc] | [prev] | [next] | [standalone]

#8025

In article <40s8b7h19580acs8ui5v06510edldnegk1@4ax.com>,
 Gene Wirchenko <genew@ocis.net> wrote:

>      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.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web