111–120 of 197 posts
Earlier quoted context omitted.
\.{1,100}@\.{1,100} I'd probably also have a red warning line under the input field for something really fishy and also most common typos (like "gmail.con") but other than that, I'd let it through.
I've had sites correct me with an email address ending in ".fi" with "are you sure you don't mean ".fr"?
This all old hat, unfortunately, and also a thing which will be gotten wrong by developers for years to come. Just shouting 'give me a regex for validating email addresses' will make an LLM like ChatGPT happily output bullshit suggesting some overlong regex which is flawed precisely as outlined by the linked article, even though no one is arguing for those long unmaintainable regexes once they've seen the light. Ah w…
The first sentence is that there is no single regex that perfectly validates every technically valid email address. I think that is a good start.
It then recommends the regex used for and explains that this would cover the majority of email addresses used by actual people. It also shows an improved regex that handles dot-atom local parts, quoted strings, domain names, and IPv4 domain literals, but doesn't cover things such as comments, full IPv6 literals, or internationalized addresses.
It ends with the only correct advice (in my optionion): Send a confirmation email.
I have a gmail address that at least three other people think is their address. I constantly get emails for the dumb stuff they sign up for. NONE of them ever have an "I didn't request this" link. I mean, I get it. That won't make them money, but oh man is it annoying.
> It is relatively expensive to run Compared to sending a mail or to a customer not getting a mail they wanted? > Try to keep it as non-restrictive as possible. Something like ^[^@]+@[^@\s]+$, which only makes sure your user has input “something@something” Requiring a dot in the domain part is perfectly valid. It makes no sense to not validate that the address is in a format that you can actually send something to, w…
yeah, that is a pretty bizarre claim, as if millions of accounts are created per second
frankly this claim makes me think this article is LLM generated, because while the claim is technically correct, it's not a real concern
The what now? I'm struggling to take this seriously because a decade ago regex where common knowledge, like if you don't have a handle on this you should probably go get a job in marketing levels of common knowledge. Has the profession fallen off this far in ten years?
Earlier quoted context omitted.
It’s really rich when banking/finance apps are fully happy doing 2FA to the phone when using its own browser… Yeah — loose the phone and it’s pretty much game over.
I don't think it should be the sites' responsibility to guess whether the browser session is the have device will receive an SMS message... The fact that it is SMS is already bad anyway. Time-code apps or passkeys are a different story. 1. You should be able to make backups. 2. There's nothing to intercept in plaintext. 3. The all can (unlike SMS features) be locked down by default and require a second layer of unloc…
One thing I have learned about verification is: Don't just put a link into your mail that directly verifies an email when visited. At least put some button or code input field there. Why? There are mail clients that will automatically open links for users and if that link is now invalid the user is confused about being able to click them.
The token was recently used? No problem! Must be a duplicate click, or a refresh, or the user left the browser tab open and their mobile device refreshed when they reopened the browser app, etc.
I would like to point out that the "suggested" validation pattern, ^[^@]+@[^@\s]+$, can filter out valid addresses. "user@something"@example.com is a valid address, and excluding @'s in the user part rejects it.
Although more recently I’ve moved to a catch all domain for throwaway, which is even better. It confuses agents on the phone though when I give my email address as {their company name}@mydomain.com
Yeah, most people don’t understand how the ownership and control varies before and after the @ symbol.
I think most of these issues are easy to resolve by being more permissive and supporting what the technical standard allows for. The Big Problem™ however is case sensitivity in the local-part, because there multiple incompatible things collide: 1. Users are not universally aware of case (in)sensitivity in one direction or the other 2. Existing systems may or may not interpret case at all My preferred solution would b…
- what case you use to send mails
- what rules you use to determine if two email strings are the same user
For the first you can and should always use the address exactly as entered. For the second that's going to be a guess anyway and the exact rules depend on what false positives and false negatives mean for your use case - and you are going to have at least one of those two. Assuming case insensitivity here is generally reasonable for most use cases.