91–100 of 228 posts
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…
I am :)
I tell everyone the same thing about access control. Don't check access. Also, never check file existence. These things just take up time, introduce race conditions, and can't be trusted anyway. That said, there are reasons to want to check some things with UI-level validation because calls to a slow back end are slow. Thus the name. I get that. So if you're doing UI validation, don't get it right. Just get it mostly…
> 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.
[0] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
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…
Can't upvote this enough. There simply is no need to check the email addr provided by the user. Send the mail, if it bounces, the user has only himself to blame. What if I don't want them to go through the hassle of an activation link? Then I don't bother with an email account in the sign-up process in the first place. If they want a passwd reset method, they can later provide an email in their settings page, if that…
What's much more important than validating the syntax of the e-mail is not to let your service be turned into a relay for targeting e-mail addresses of third parties with "backscatter". Don't put up a web page where any visitor can put in an e-mail address, to which you send something, without any safeguards: like not sending to the same e-mail address more than just several times in a 24 hour period or something. Ha…
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…
Typos will overwhelmingly lead to valid-looking addresses anyway.
Earlier quoted context omitted.
> it's needed sometimes When is this needed in the context of a Rails app? You never want to send emails to local hosts, and emails directly on the TLD is possible, but very little will work with them in practice.
> You never want to send emails to local hosts That's not entirely true, it depends on how your mailing infrastructure is set up.
2) if second level domain not in list of famous second level domains, AND levenschtein distance is small with a domain on the list (typically gmial, oultook, yhaoo,...), display a huge warning. Don't refuse if the user insists it's correct, but show a huge and red warning that blinks. Same with the TLD to detect "cmo", "ogr", "inof" etc.
3) Maybe send a validation email, now that you've ruled out a big number of potential mistakes. You won't get that many bounces. Or don't send the email if you don't need to!
I fail to imagine a scenario that wouldn't be neatly covered by this 3-step process.
Can't upvote this enough. There simply is no need to check the email addr provided by the user. Send the mail, if it bounces, the user has only himself to blame. What if I don't want them to go through the hassle of an activation link? Then I don't bother with an email account in the sign-up process in the first place. If they want a passwd reset method, they can later provide an email in their settings page, if that…
Some products don’t want to let users fail so easily. Especially if they spent good money to get you to the point of signing up.
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.
You’re right that you can’t prevent someone from typing their address incorrectly, but you can make sure they didn’t put in their phone number or their first name by mistake