171–180 of 228 posts
I've been seeing this kind of argument from the mid-levels on my current team, paraphrased like this: "I am having a hard time understanding this, therefore it needs to change."
Validate emails in a manner that is representative of the typical use of your service. If it’s a specialist email processing tool, then you should probably follow an RFC. If it’s a dating app, you can probably just use a regex that covers common cases to help users avoid typos. I think the decision is similar to the one picking how modern are the browsers you are going to support. It’s a trade-off. That’s my take on…
You will want to check ownership by sending a verification email anyway. If you want to avoid typos, show a "are you sure... yes/no" warning, there is no need to block anybody. Typos will overwhelmingly lead to valid-looking addresses anyway.
Being too generous in the early input validation regex (e.g just check for non empty and containing one @) risks making registrations fail and customers not returning. This seems like a much bigger risk than locking anyone out who has a weird email Even a character beyond [a-z0-9-_] or domain without tld is probably worth rejecting.
1) simple regex to rule out the common typos such as 2 or 0 @, no period in the domain name, etc. I don't care about people whose domain name consists of a TLD only. Bring your nerdiness somewhere else, every other service is already rejecting your exotic e-mail address already anyway. Same for spaces in the local part of the address, etc. 2) if second level domain not in list of famous second level domains, AND leve…
> I don't care about people whose domain name consists of a TLD only. I’ve never understood this, but heard it often from developers and product owners in the industry. “I don’t care about the small number of users who X” where accommodating X is essentially free. Or worse: deliberately taking the eng time to reject users X where accepting takes no work! Especially in a business context where users X are trying to ha…
RFCs for email addresses are cool, but on the web we have our own standards! https://html.spec.whatwg.org/multipage/input.html#valid-e-ma... "This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manner…
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…
Earlier quoted context omitted.
Please don't check for a full-stop/period. It excludes those who have their email address directly on a TLD.
No it doesn't. Those require a dot at the end. Without a dot, it's a hostname not a TLD.
Earlier quoted context omitted.
I have my own domain and a catch-all setup, so when I sign up for a service, it's the-service-name@my-domain-name.com, if I give someone my email address, it's their-name@my-domain-name.com It makes it easy for me to keep track of who is sending me what + who is sharing my email with third parties, but definitely confuses some people.
Samsung is particularly annoying about this. You can't sign up for an account with "Samsung" in the user portion. They'll straight up block samsung@yourdomain.net, so I've resorted to misspelling their name in the email address and they seem perfectly fine with that.
I've been seeing this kind of argument from the mid-levels on my current team, paraphrased like this: "I am having a hard time understanding this, therefore it needs to change."
That can be a valid complaint as long as it's not about the logic or rules themselves, but how they're expressed in the code. Code that your team members can't work on is a liability.
I see complexity as kind of a mass, and our job is in part to reduce it as far as possible.
Like mass, you can shuffle complexity around, or add more, or discover unexpected ways to reduce it, but there is no way to reduce it below the problem's lower bound.
Sometimes, the solution is as simple as it's going to get, and it's still complicated. State management is a good example.
I'm more referring to that situation.
This article's headline is an example of the argument I mean. If not using Regex is the proposal for reducing complexity, it's not going to reduce complexity.
RFCs for email addresses are cool, but on the web we have our own standards! https://html.spec.whatwg.org/multipage/input.html#valid-e-ma... "This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manner…
If you really want to take validation seriously, why not add a human element to it, and not design one line of code to try to fix everything? One of the biggest problems with email input is typos -- and there are some very common typos that could easily be accounted for with code. For example foo@gmail.co, foo@gmial.com, foo@comcast, etc. It should be common, when these types of typos occur, to prompt the user to fix…
I wrote an email validating regex at one point. It checked that there was exactly one @ sign in the address, which was neither the first nor last character. Seemed like a pretty good compromise to me.
Earlier quoted context omitted.
You will want to check ownership by sending a verification email anyway. If you want to avoid typos, show a "are you sure... yes/no" warning, there is no need to block anybody. Typos will overwhelmingly lead to valid-looking addresses anyway.
You might want “clean” or “normal” addresses too (for whatever reason). For example, disallowing “+” would just give you the canonical email instead of one that risks being tagged with a unique ID revealing who leaked it. Being too generous in the early input validation regex (e.g just check for non empty and containing one @) risks making registrations fail and customers not returning. This seems like a much bigger…