It's a whole bloody eShop platform that fails these!
bugs.oxid-esales.com/view.php?id=65
IT WAS REPORTED IN 2016!
Conversation
what the actual! You know for five years that you're rejecting people's email addresses as invalid because of a lazy regular expression!
I wrote about this _twelve_ years ago!
1
Wait, this was also _fixed_ five years ago! github.com/OXID-eSales/fl
Is running a >5 years old web app???
1
1
1
I love this patch, but the new regex is still wrong. It rejects ppl who spend tens of thousands of dollars on their own TLD for an address with no dots in it.
1
1
I mean there's no freaking way to validate an email address with a regex.
So just give up?
1
1
It makes no sense to use a regex though, because you can use a type=email input in a web page and check it with the library you use to send emails before saving it.
Proper input field and `new InternetAddress(email).validate();` is all that attestation.app does with it.
1
1
As it turns out *that* is the library they were using to do the browser-side validation.
The backend didn't do any validation and let me register just fine after that.
1
2
Jakarta Mail is the library we use for AttestationServer and even that doesn't bother checking all the validity rules.
jakarta.ee/specifications
It checks enough though, and doesn't wrongly reject something like a@a as invalid. It avoids causing harm, which is what matters.
1
1
You'd be surprised how many programmers try to be smart and are not.
Sigh.
1
2
Meanwhile, even Internet Explorer 10 has type=email support:
caniuse.com/input-email-te
It's ridiculous to use anything more than that since it works perfectly well and gives nice errors with the standard UI. I go out of the way to use caniuse.com/constraint-val to match that UI too.
Modern browsers have nice support for form validity checking. Can provide the same UI for your custom client-side or server-side checks. Don't really understand why everything is so over-engineered and broken instead. Guess people are paid by lines of code written or something.
1