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

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

Restrict a domain on Email Validation

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

Contents

  Restrict a domain on Email Validation GarryJones <morack@algonet.se> - 2013-04-11 10:33 -0700
    Re: Restrict a domain on Email Validation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-11 20:40 +0200
      Re: Restrict a domain on Email Validation Stefan Weiss <krewecherl@gmail.com> - 2013-04-11 20:53 +0200
        Re: Restrict a domain on Email Validation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-11 21:09 +0200
          Re: Restrict a domain on Email Validation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-11 21:35 +0200
          Re: Restrict a domain on Email Validation Stefan Weiss <krewecherl@gmail.com> - 2013-04-11 21:49 +0200
            Re: Restrict a domain on Email Validation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-11 22:04 +0200
              Re: Restrict a domain on Email Validation Stefan Weiss <krewecherl@gmail.com> - 2013-04-11 23:25 +0200
                Re: Restrict a domain on Email Validation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-11 23:31 +0200
                  Re: Restrict a domain on Email Validation Stefan Weiss <krewecherl@gmail.com> - 2013-04-12 00:23 +0200
                    Re: Restrict a domain on Email Validation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-12 00:42 +0200
                      Re: Restrict a domain on Email Validation Stefan Weiss <krewecherl@gmail.com> - 2013-04-13 11:36 +0200
                        Re: Restrict a domain on Email Validation Scott Sauyet <scott.sauyet@gmail.com> - 2013-04-20 13:30 -0700
      Re: Restrict a domain on Email Validation Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-12 00:51 +0200
    Re: Restrict a domain on Email Validation Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-04-12 19:36 +0100
      Re: Restrict a domain on Email Validation "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-04-13 10:40 +0200

#19221 — Restrict a domain on Email Validation

I am currently using this code to validate emailadresses on user forms.

function checkform ( form ){
  if (!(/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(form.bokept.value))){
    var answer = confirm("Invalid or incorrect email address
      \n Click Cancel if you want to try again
      \n Click OK if you don't have an email address
      \n Click OK if our system does not allow your email adress
      \n If you click OK we will insert a dummy email address for our purposes")
    if (answer){form.bokpap.checked = true;
      form.bokept.value = 'missemail@mydomain.se'; 
      return false ;
    } else {
      form.bokept.focus();
      form.bokept.value = '';
      return false ;
    }
  }
 return true ;
}

This has served me well since 2005.

Now I need to make a change.

I can no longer allow users to use email addresses from a certain domain.

How can I change the script to block all email addresses from @forbidden.*

(Where * can be org, com. co.uk, se ...... etc)

?

Any help greatly appreciated.

Garry Jones
Sweden

[toc] | [next] | [standalone]

#19230

GarryJones wrote:
^^^^^^^^^^
There should be a space character between first and last name so as not to 
appear as a pseudonym and being subject to the respective filters.

> I am currently using this code to validate emailadresses on user forms.
> 
> function checkform ( form ){

Code conventions:

  function checkForm (form) {

or

  function checkForm (form)
  {

I prefer the latter in order to tell function expressions and function 
declarations apart.

>   if
>   (!(/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/

Wrong, see RFC 5322 (and predecessors newer than RFC 822).

> .test(form.bokept.value))){

    .test(form.elements["bokept"].value))
  {

>     var answer = confirm("Invalid or incorrect email address
                                                              ^
Unterminated string literal ----------------------------------'

>       \n Click Cancel if you want to try again
>       \n Click OK if you don't have an email address
>       \n Click OK if our system does not allow your email adress
>       \n If you click OK we will insert a dummy email address for our
>       purposes")
>     if (answer){form.bokpap.checked = true;
>       form.bokept.value = 'missemail@mydomain.se';

You really do not want to include e-mail addresses (verbatim) in client-side 
code.  Also, do not use potentially existing domains for dummy values or 
examples.  Use the “invalid” top-level and “example” top-level and second-
level domains.  See RFC 2606.

>       return false ;

Convention is: No space before “;”.

>     } else {
>       form.bokept.focus();
>       form.bokept.value = '';

Proprietary referencing; avoid, see above.

>       return false ;

See above.

>     }
>   }
>  return true ;

See above.

> }
> 
> This has served me well since 2005.

Doubtful, as it does not compile due to syntax errors.
 
> Now I need to make a change.
> 
> I can no longer allow users to use email addresses from a certain domain.
> 
> How can I change the script to block all email addresses from @forbidden.*

  … 
  && !/@forbidden\.[^.]+$/.test(…)

As you can see here, it is not necessary to put the test() call in 
parentheses.

> (Where * can be org, com. co.uk, se ...... etc)
> 
> ?
> 
> Any help greatly appreciated.

Adaptation of the client-side code certainly helps to reduce unnecessary 
roundtrips.  But you must also check potential addresses server-side to 
fulfill the requirement.  (You should have done so before.)

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#19231

On 2013-04-11 20:40, Thomas 'PointedEars' Lahn wrote:
> GarryJones wrote:
>> How can I change the script to block all email addresses from @forbidden.*
> 
>   … 
>   && !/@forbidden\.[^.]+$/.test(…)
...
>> (Where * can be org, com. co.uk, se ...... etc)

That pattern won't match "@forbidden.co.uk".

- stefan

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

#19232

Stefan Weiss wrote:

> On 2013-04-11 20:40, Thomas 'PointedEars' Lahn wrote:
>> GarryJones wrote:
>>> How can I change the script to block all email addresses from
>>> @forbidden.*
>> 
>>   …
>>   && !/@forbidden\.[^.]+$/.test(…)
> ...
>>> (Where * can be org, com. co.uk, se ...... etc)
> 
> That pattern won't match "@forbidden.co.uk".

Correct.  Use

  …
  && !/@forbidden(\.[^.]+)+$/.test(…)

or 

  …
  && !/@forbidden(\..+?)+$/.test(…)

then (the former is backwards-compatible and presumably more efficient than 
the latter).  You may also want to insert “\s*” before “$” to account for 
trailing whitespace.  The RegExp constructor comes in handy here with regard 
to an easily maintained list of allowed characters (which reminds me to look 
into pattern interpolation for jsx.regexp.RegExp).

In any case, the expression appropriate for this task can be derived from 
RFC 5322, section 3.4.1.  (I have pos[i]ted the approach before, but I do 
not know the Message-ID.)

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#19233

Thomas 'PointedEars' Lahn wrote:

>   …
>   && !/@forbidden(\..+?)+$/.test(…)
> 
> […]  The RegExp constructor comes in handy here with regard to an easily
> maintained list of allowed characters (which reminds me to look into
> pattern interpolation for jsx.regexp.RegExp).

I almost forgot:

  jsx.regexp.RegExp.definePropertyClasses({
    atext: "\\w!#$%&'*+/=?^`{|}~-"
  });

  if (…
      && !(new jsx.regexp.RegExp("@forbidden(\\.\\p{atext}+?)+$")).test(…))
  {
    …
  }

(In V8 also with a RegExp literal as argument and no double escaping :))

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#19234

On 2013-04-11 21:09, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> On 2013-04-11 20:40, Thomas 'PointedEars' Lahn wrote:
>>> 
>>>   && !/@forbidden\.[^.]+$/.test(…)
...
>> That pattern won't match "@forbidden.co.uk".
> 
> Correct.  Use
> 
>   …
>   && !/@forbidden(\.[^.]+)+$/.test(…)
> 
> or 
> 
>   …
>   && !/@forbidden(\..+?)+$/.test(…)

Okay, but that also matches "@forbidden.planet.example.com". In
conjunction with the OP's original regex, looking for the substring
"@forbidden." would do the same thing.

I don't see any simple and correct general solution for this with a
single regular expression, unless we want to enumerate all currently
known top level domains and their associated reserved second level
domains. Which, by the way, is going to be quite a task soon, because
about 2000 new TLDs are expected to be assigned this year.

- stefan

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

#19235

Stefan Weiss wrote:

> On 2013-04-11 21:09, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> On 2013-04-11 20:40, Thomas 'PointedEars' Lahn wrote:
>>>> 
>>>>   && !/@forbidden\.[^.]+$/.test(…)
> ...
>>> That pattern won't match "@forbidden.co.uk".
>> 
>> Correct.  Use
>> 
>>   …
>>   && !/@forbidden(\.[^.]+)+$/.test(…)
>> 
>> or
>> 
>>   …
>>   && !/@forbidden(\..+?)+$/.test(…)
> 
> Okay, but that also matches "@forbidden.planet.example.com".

So?

> In conjunction with the OP's original regex, looking for the substring
> "@forbidden." would do the same thing.

No, (!x && !y) is logically equivalent to !(x || y).

> I don't see any simple and correct general solution for this with a
> single regular expression, unless we want to enumerate all currently
> known top level domains and their associated reserved second level
> domains. Which, by the way, is going to be quite a task soon, because
> about 2000 new TLDs are expected to be assigned this year.

Maybe you are just thinking about a different problem.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#19236

On 2013-04-11 22:04, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> On 2013-04-11 21:09, Thomas 'PointedEars' Lahn wrote:
>>> Stefan Weiss wrote:
>>>> On 2013-04-11 20:40, Thomas 'PointedEars' Lahn wrote:
>>>>> 
>>>>>   && !/@forbidden\.[^.]+$/.test(…)
>> ...
>>>> That pattern won't match "@forbidden.co.uk".
>>> 
>>> Correct.  Use
>>> 
>>>   …
>>>   && !/@forbidden(\.[^.]+)+$/.test(…)
>>> 
>>> or
>>> 
>>>   …
>>>   && !/@forbidden(\..+?)+$/.test(…)
>> 
>> Okay, but that also matches "@forbidden.planet.example.com".
> 
> So?

So it doesn't solve the problem as stated:

| block all email addresses from @forbidden.*
| (Where * can be org, com. co.uk, se ...... etc)

forbidden.planet.example.com is clearly a false positive.

>> In conjunction with the OP's original regex, looking for the substring
>> "@forbidden." would do the same thing.
> 
> No, (!x && !y) is logically equivalent to !(x || y).

You're contradicting an imaginary statement - I never even mentioned any
operators. To be clear, for the purpose of testing if the domain name
part "forbidden" follows the @-sign,

   if (!(/original-regex/.test(str) && !/your-regex/.test(str)))

is equivalent to

   if (!(/original-regex/.test(str) && str.indexOf("@forbidden.") < 0))

or, with the negated parenthesized expression resolved,

   if (!/original-regex/.test(str) || str.indexOf("@forbidden.") > -1)


The point is that none of these really solve the OP's problem
(but they might be sufficient for his purposes, anyway).


- stefan

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

#19237

Stefan Weiss wrote:

> On 2013-04-11 22:04, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> On 2013-04-11 21:09, Thomas 'PointedEars' Lahn wrote:
>>>> Stefan Weiss wrote:
>>>>> On 2013-04-11 20:40, Thomas 'PointedEars' Lahn wrote:
>>>>>> 
>>>>>>   && !/@forbidden\.[^.]+$/.test(…)
>>> ...
>>>>> That pattern won't match "@forbidden.co.uk".
>>>> 
>>>> Correct.  Use
>>>> 
>>>>   …
>>>>   && !/@forbidden(\.[^.]+)+$/.test(…)
>>>> 
>>>> or
>>>> 
>>>>   …
>>>>   && !/@forbidden(\..+?)+$/.test(…)
>>> 
>>> Okay, but that also matches "@forbidden.planet.example.com".
>> 
>> So?
> 
> So it doesn't solve the problem as stated:
> 
> | block all email addresses from @forbidden.*
> | (Where * can be org, com. co.uk, se ...... etc)
> 
> forbidden.planet.example.com is clearly a false positive.

Your logic is flawed.  “...... etc” makes it clear that *any* domain name 
whose bottom level is named “forbidden” is to be rejected, including 
forbidden.planet.example.com.

>>> In conjunction with the OP's original regex, looking for the substring
>>> "@forbidden." would do the same thing.
>> 
>> No, (!x && !y) is logically equivalent to !(x || y).
> 
> You're contradicting an imaginary statement - I never even mentioned any
> operators. To be clear, for the purpose of testing if the domain name
> part "forbidden" follows the @-sign,
> 
>    if (!(/original-regex/.test(str) && !/your-regex/.test(str)))
> 
> is equivalent to
> 
>    if (!(/original-regex/.test(str) && str.indexOf("@forbidden.") < 0))
> 
> or, with the negated parenthesized expression resolved,
> 
>    if (!/original-regex/.test(str) || str.indexOf("@forbidden.") > -1)

No, it is not.  Your logic is flawed.
 
> The point is that none of these really solve the OP's problem
> (but they might be sufficient for his purposes, anyway).

The expression that I posted does solve the OP's problem; you have just 
misunderstood the problem.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#19238

On 2013-04-11 23:31, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> So it doesn't solve the problem as stated:
>> 
>> | block all email addresses from @forbidden.*
>> | (Where * can be org, com. co.uk, se ...... etc)
>> 
>> forbidden.planet.example.com is clearly a false positive.
> 
> Your logic is flawed.  “...... etc” makes it clear that *any* domain name 
> whose bottom level is named “forbidden” is to be rejected, including 
> forbidden.planet.example.com.

That's a *very* generous interpretation of "etc".

If that's indeed how you read it, the whole problem becomes trivial.
In that case, I wonder why you would prefer a regular expression to
indexOf().

>> To be clear, for the purpose of testing if the domain name
>> part "forbidden" follows the @-sign,
>> 
>>    if (!(/original-regex/.test(str) && !/your-regex/.test(str)))
>> 
>> is equivalent to
>> 
>>    if (!(/original-regex/.test(str) && str.indexOf("@forbidden.") < 0))
>> 
>> or, with the negated parenthesized expression resolved,
>> 
>>    if (!/original-regex/.test(str) || str.indexOf("@forbidden.") > -1)
> 
> No, it is not.  Your logic is flawed.

Saying "no" and "your logic is flawed" means nothing (especially coming
from you). If you find anything to disprove the statement, let me know;
until then I'll just consider you too stubborn to admit a mistake.

> The expression that I posted does solve the OP's problem; you have just 
> misunderstood the problem.

We have apparently interpreted the OP's question in different ways.
It will be up to him to clear it up.


- stefan

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

#19239

Stefan Weiss wrote:

> On 2013-04-11 23:31, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> So it doesn't solve the problem as stated:
>>> 
>>> | block all email addresses from @forbidden.*
>>> | (Where * can be org, com. co.uk, se ...... etc)
>>> 
>>> forbidden.planet.example.com is clearly a false positive.
>> 
>> Your logic is flawed.  “...... etc” makes it clear that *any* domain name
>> whose bottom level is named “forbidden” is to be rejected, including
>> forbidden.planet.example.com.
> 
> That's a *very* generous interpretation of "etc".

You must be kidding.  That (anything of the same sort) is the very meaning 
of ”etc.” – et cetera – and so on.  I do not think the program (or problem) 
specification could be more clear in that respect: “*” is used as a 
placeholder here; it is defined by examples afterwards, where the list of 
examples is _not_ exhaustive, due to “etc.”  Much like saying “Even numbers, 
like 2, 4, 6, etc.” by definition includes 42.
 
> If that's indeed how you read it, the whole problem becomes trivial.
> In that case, I wonder why you would prefer a regular expression to
> indexOf().

Because – again – indexOf() is _not_ equivalent.

>>> To be clear, for the purpose of testing if the domain name
>>> part "forbidden" follows the @-sign,
>>> 
>>>    if (!(/original-regex/.test(str) && !/your-regex/.test(str)))
>>> 
>>> is equivalent to
>>> 
>>>    if (!(/original-regex/.test(str) && str.indexOf("@forbidden.") < 0))
>>> 
>>> or, with the negated parenthesized expression resolved,
>>> 
>>>    if (!/original-regex/.test(str) || str.indexOf("@forbidden.") > -1)
>> 
>> No, it is not.  Your logic is flawed.
> 
> Saying "no" and "your logic is flawed" means nothing (especially coming
> from you). If you find anything to disprove the statement, let me know;
> until then I'll just consider you too stubborn to admit a mistake.

No, this is not how a proper discussion works.  You are to prove your 
argument first.  You will see then that you are wrong.

HTH

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#19253

On 2013-04-12 00:42, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> On 2013-04-11 23:31, Thomas 'PointedEars' Lahn wrote:
>>> Stefan Weiss wrote:
>>>> | block all email addresses from @forbidden.*
>>>> | (Where * can be org, com. co.uk, se ...... etc)
>>>> 
>>>> forbidden.planet.example.com is clearly a false positive.
>>> 
>>> Your logic is flawed.  “...... etc” makes it clear that *any* domain name
>>> whose bottom level is named “forbidden” is to be rejected, including
>>> forbidden.planet.example.com.
>> 
>> That's a *very* generous interpretation of "etc".
> 
> You must be kidding.  That (anything of the same sort) is the very meaning 
> of ”etc.” – et cetera – and so on.  I do not think the program (or problem) 
> specification could be more clear in that respect: “*” is used as a 
> placeholder here; it is defined by examples afterwards, where the list of 
> examples is _not_ exhaustive, due to “etc.”  Much like saying “Even numbers, 
> like 2, 4, 6, etc.” by definition includes 42.

Unless the OP returns to clarify what he meant, we'll never find out.
You chose to go letter-of-the-law and interpret "etc" as "anything
goes", which reduces the problem to a trivial check. I chose to read
between the lines and interpret "etc" as top-level domain plus possibly
a reserved second-level domain suffix (as in the case of "co.uk"). That
problem is a lot harder to solve.

What makes more sense to you, that somebody doesn't want email addresses
for company.de, company.co.uk, company.com.tr, or maybe even
affiliates.company.de entered in their forms, or that they don't want
the word "company" to appear as the first word of the mail domain part
for some reason?

>> If that's indeed how you read it, the whole problem becomes trivial.
>> In that case, I wonder why you would prefer a regular expression to
>> indexOf().
> 
> Because – again – indexOf() is _not_ equivalent.

You keep saying that, but have yet to provide any explanation. And no,
"your logic is flawed" is not an explanation. See below.

>>>> To be clear, for the purpose of testing if the domain name
>>>> part "forbidden" follows the @-sign,
>>>> 
>>>>    if (!(/original-regex/.test(str) && !/your-regex/.test(str)))
>>>> 
>>>> is equivalent to
>>>> 
>>>>    if (!(/original-regex/.test(str) && str.indexOf("@forbidden.") < 0))
>>>> 
>>>> or, with the negated parenthesized expression resolved,
>>>> 
>>>>    if (!/original-regex/.test(str) || str.indexOf("@forbidden.") > -1)
>>> 
>>> No, it is not.  Your logic is flawed.
>> 
>> Saying "no" and "your logic is flawed" means nothing (especially coming
>> from you). If you find anything to disprove the statement, let me know;
>> until then I'll just consider you too stubborn to admit a mistake.
> 
> No, this is not how a proper discussion works.  You are to prove your 
> argument first.  You will see then that you are wrong.

Prove my argument? What do you expect me to do, formally prove the
correctness of code? That's a notoriously difficult and time consuming
problem, and hardly necessary here. You can read JavaScript code, and I
would have expected you to understand what it does. But for the record:
while the OP's original regex is not a good test for valid email
addresses, it ensures that there can only be a single @-sign in the
string, that it is surrounded by at least one word character on either
side, and that only [\w@.-] can appear in the string. Given that, a
substring search for "@forbidden." is all that is required to check
whether the first part of the address domain part is "forbidden". Using
a regex will not improve that test. That's what I said and that's what
you're contradicting. I may be wrong, but now it's up to you to explain why.

The equivalence I claimed cannot be proven with a finite number of
examples, but it only takes a single counter example to falsify it.
Since you're so certain that they are not equivalent, it should be easy
enough for you to provide such an example (not that I expect you to).

As for "proper discussions"... past experience has shown that any
attempt at having a proper discussion with you is an exercise in
futility. In contrast to you, the time I'm willing to spend in this
group is limited; if you prefer to mince words and demand impossible
proofs instead of discussing code, don't expect a reply.

- stefan

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

#19380

Stefan Weiss wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> Thomas 'PointedEars' Lahn wrote:

>>>> [ ... ]
>>>> No, it is not.  Your logic is flawed.
>
>>> Saying "no" and "your logic is flawed" means nothing (especially coming
>>> from you). If you find anything to disprove the statement, let me know;
>>> until then I'll just consider you too stubborn to admit a mistake.
>
>> No, this is not how a proper discussion works.  You are to prove your
>> argument first.  You will see then that you are wrong.
>
> Prove my argument? What do you expect me to do, formally prove the
> correctness of code? That's a notoriously difficult and time consuming
> problem, and hardly necessary here. You can read JavaScript code, and I
> would have expected you to understand what it does.  [ ... clear
> explanation snipped for brevity ... ] I may be wrong, but now it's up
> to you to explain why.
>
> The equivalence I claimed cannot be proven with a finite number of
> examples, but it only takes a single counter example to falsify it.
> Since you're so certain that they are not equivalent, it should be easy
> enough for you to provide such an example [ ... ]

And, a week later, no response.  Amazing how dismissive one can be
with a phrase like "your logic is flawed" even with absolutely no
reasonable argument to back it up.

  -- Scott

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

#19242

Thomas 'PointedEars' Lahn wrote:

> GarryJones wrote:
>> Now I need to make a change.
>> 
>> I can no longer allow users to use email addresses from a certain domain.
>> 
>> How can I change the script to block all email addresses from
>> @forbidden.*
> 
>   …
>   && !/@forbidden\.[^.]+$/.test(…)

To fit your business logic, make that “&&” an “||” and remove the “!”.  
(AIUI, you wanted to allow for the dummy address in case of a forbidden 
[pseudo-]address.)

  if (!… || …)
  {
    …
  }
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#19249

In comp.lang.javascript message <9e42c475-f0f4-4822-98d4-0291745f3447@go
oglegroups.com>, Thu, 11 Apr 2013 10:33:04, GarryJones
<morack@algonet.se> posted:

>I am currently using this code to validate emailadresses on user forms.
>
>function checkform ( form ){
>  if (!(/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(form.bokep
>t.value))){

That RegExp will reject, according to test, at least one perfectly valid
E-mail address; and therefore a large number of valid addresses.  You
should find out the requirements for a valid address before attempting
validation.

There is little point in attempting strict format validation, since the
more important problem is exemplified by an input of 'microsoft.com' by
someone wanting 'microsort.com'.

The only sensible test is that the pattern is not OBVIOUSLY AND
CERTAINLY invalid; so test with /.+@.+\..+/ (untested; see cited site)
[and consider that E-mail address right parts can be in purely numeric
form {IPv4 & IPv6 or other terminology}].


>This has served me well since 2005.

Except that a probably-unknown number of addresses have been incorrectly
deemed invalid.

Your code additionally rejects addresses with trailing whitespace; it
would generally be better to trim leading and trailing whitespace before
doing anything else.


>How can I change the script to block all email addresses from @forbidden.*

Then use another RegExp test to reject any string matching
/@forbidden.*/ (though it might be wise to allow ones from postmaster @
anywhere).

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


-- 
 (c) John Stockton, nr London UK               Reply address via Home Page.
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

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

#19251

Dr J R Stockton wrote on 12 apr 2013 in comp.lang.javascript:

> Then use another RegExp test to reject any string matching
> /@forbidden.*/ 

/@forbidden\./

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]

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

csiph-web