This is the kind of easy to fix, hard to review bug. Email validation
make uses of strings listing characters, those strings are then
enclosed between brackets "[]". Inside brackets, the hyphen is used
to describe a range of character [a-d] being a b c d.
The string containing an unescaped hyphen, made JS/PHP validation
to match the incorrect comma ",".
* Backslash hyphen
* JS,PHP: add tests for commas and hyphens in username or domain
* JS: add var to rfc_1034_ldh_str
* JS: minor code cleanup
TESTS:
php phpunit.php -c suite.xml --filter ValidEmail
OK (13 tests, 32 assertions)
Special:BlankPage?action=mwutiltest&debug=true
Ran 66 tests. 66 passed test(s). 0 error(s). 0 partially passed test(s).
In r75682, I have implemented a PHP function to validate email address
based on bug 22449. Siebrand pointed a w3.org specification which I
implemented. The spec is bugged since it requires a domain and a top
level domain!
I could either make the first part optional or alter the second part
to require 0 to x elements. I choose the later: s/+/*/
Should fix bug 22449 for good.
TESTS:
Added testEmailDoesNotNeedATopLevelDomain:
Made following emails valid:
user.@localdaomin
.@localdomain
user@a
Test output (please add more):
$ php phpunit.php -c suite.xml --filter alidEmail --tap
TAP version 13
ok 1 - UserIsValidEmailAddrTest::testEmailWellKnownUserAtHostDotTldAreValid
ok 2 - UserIsValidEmailAddrTest::testEmailWithUpperCaseCharactersAreValid
ok 3 - UserIsValidEmailAddrTest::testEmailWithAPlusInUserName
ok 4 - UserIsValidEmailAddrTest::testEmailDoesNotNeedATopLevelDomain
ok 5 - UserIsValidEmailAddrTest::testEmailWithWhiteSpacesBeforeOrAfterAreInvalids
ok 6 - UserIsValidEmailAddrTest::testEmailWithWhiteSpacesAreInvalids
ok 7 - UserIsValidEmailAddrTest::testEmailDomainCanNotBeginWithDot
ok 8 - UserIsValidEmailAddrTest::testEmailWithFunnyCharacters
ok 9 - UserIsValidEmailAddrTest::testEmailTopLevelDomainCanBeNumerical
ok 10 - UserIsValidEmailAddrTest::testEmailWithoutAtSignIsInvalid
ok 11 - UserIsValidEmailAddrTest::testEmailWithOneCharacterDomainIsValid
1..11
This might avoid confusion when testing. Currently, an email without
a tld is invalid (ex user@host). The assertions could have been
invalid just by the lack of tld, not the spaces!
