This won't be popular, but: 1. An experienced dev just killed 54k stars on GitHub due to pressing a button in an auto-pilot mode. Do you think a Joe High who wants to give you $100 won't ever type '2' instead of '@'? What about an old lady? Or someone with physical difficulties? Have you personally ever made a typo in an email? 2. That code in the article is not color highlighted (rainbowed for Regex) or formatted pr…
> 5. I'm not a Regex fanboy (nobody is). I am :)
Me, too! They can be complex or wrong, but just as often they're a decently simple way that every programmer understands to check something.
The only way to validate an email is to send a message to the email address. Validating that it fits the rfc is pointless, because a) its very easy to create an email that is both false and meets the rfc, b) email provider might bypass the rfc and the email would still be working. To validate user input, I use that: /^[^@]+@[^.]+\..+$/. It's doesn't tell me if the email is semantically correct per the rfc because I'm…
It isn’t pointless. It is fast feedback for typos and form validation
A regex won't catch typos. Send an email, or if you really want force to enter twice. The rfc is both so permissive and generic that pretty much anything will pass it, while at the same time it is very hard to test it, so you might block legitimate ones. MSFT for example allows you to use your personal email as a MSFT account. If you username is less than 3 letters some of the validation they do in some of the subsystems will reject it as invalid that they even validated with a confirmation email. I can't count the number of systems which reject + in a username or a subdomain in the host. Truly you're just making it harder for the users and for yourself.
I tried using that expression for a while, but then a user with a valid email address containing upper unicode characters showed up. I switched to a simpler expression: ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$ It requires exactly one "@", disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn't end with a dot. It catches a few typos and…
Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)
> Domains ending with a dot are valid though,
That doesn't mean you have to support their use. I have never seen a company support an email ending in a period and the world seems to continue along.
> I tell everyone the same thing about access control. Don't check access. This caught my eye and I’m dying to know more - could you elaborate or point me to a good resource on this? My team has been dealing with some issues related to this recently.
It may be in reference to TOCTOU. [0] If you check that you can access a resource before you access that resource, you have implemented a race condition where you could potentially lose access to the resource in between the check and access attempt. It's probably not an issue if you have proper error handling, but it seems common to check that access is allowed then assume the resource will still be accessible later,…
`+` is a legal part of the mailbox name everywhere but gmail (and gmail clones). Broken "checks" like these are exactly what the simple validation is avoiding.
If people who use '+' on purpose are fewer than those who type it in error (who type bobsmith+ when they meant bobsmith0, then it might not be a good idea. The entire argument I was trying to make was that what constitutes a "legal email address" is not always what you want to validate. That some providers allow using '+' isn't as important as the number of users that actually do. If some nontrivial number of users u…
Why do you believe that? What do you gain by rejecting '+', no matter how few people need it to work?
`+` is a legal part of the mailbox name everywhere but gmail (and gmail clones). Broken "checks" like these are exactly what the simple validation is avoiding.
If people who use '+' on purpose are fewer than those who type it in error (who type bobsmith+ when they meant bobsmith0, then it might not be a good idea. The entire argument I was trying to make was that what constitutes a "legal email address" is not always what you want to validate. That some providers allow using '+' isn't as important as the number of users that actually do. If some nontrivial number of users u…
You should also reject `z` in emails. The number of users who type this accidentally no doubt greatly exceeds the number who actually have that letter in their email address.
One important aspect of this that I often see people forgetting is that this check is designed for working with ASCII, but the domain name at least can be non-ASCII. User interfaces should remember to support IDN in domain labels and convert it to punycode before validating, and if you store A-labels (which you probably do) then convert it back to IDN form when presenting it to users. (Alas, still doesn’t support non…
I thought they've rolled back most of this because it made phishing domains indistinguishable from the real ones? I used an-emoji.my.domain for a while until chrome changed it back to punycode
I thought they've rolled back most of this because it made phishing domains indistinguishable from the real ones? I used an-emoji.my.domain for a while until chrome changed it back to punycode
I erred slightly in what I wrote there; I said IDN form for user display, but should have said IDNA form , which is the set of restrictions to mitigate those hazards. That will allow things like उदाहरण.example, while leaving emoji as xn--n3h.example since they’re not valid in IDNA. See also https://en.wikipedia.org/wiki/Internationalized_domain_name and https://en.wikipedia.org/wiki/Emoji_domain .
Actually, I’ve got to add another note because my memory and experience was insufficient here: see also https://en.wikipedia.org/wiki/IDN_homograph_attack#Client-si... for descriptions of what further restrictions browsers do, with the most notable additional filter being disallowing mixing scripts. This is something that would be nice to formalise in some way, though I don’t know of any venue suitable for the task.