Re:Complexities of e-mail validation logic
by tyoma on Monday May 24, 2021 @11:03AM
(#27265189)
The best are sites that let you sign up with a ‘+’ but not log in. Zappos used to be the most prominent example.
[ Parent
| on HN ]
Re:Complexities of e-mail validation logic
by PebblesRox on Monday May 24, 2021 @02:38PM
(#27268072)
Reminds me of a patio11 post (which I haven't been able to track down) where he said he gets people signing up with a '+' but then forgetting to include the extra part when they log in later. His login code accepts both versions and increments a counter to track how many people were too smart for their own good.
I've run across at least one banking site which accepted a password on the sign-up page which was later rejected by the login page. The validation scripts on the login page used a more limited set of permissible special characters which didn't include parentheses. Fortunately it was only a client-side check, so it was relatively simple to bypass it once using developer tools and change the password.
American Express at one point let me set a password over 8 characters, but logging in after only worked if I provided only the first 8.
At one point I know they also weren't case sensitive.
Why would you ever validate the characters of a password on the login page? What a weird thing to do.
I once had a site _silently strip_ the + from signup email. So when I submitted `[email protected]` as my email address, they started sending mail to `[email protected]`. Madness.
This is common; spammers know the semantics of '+' for gmail and will strip it. You need to assume that it will happen.
GP said the site stripped the “+” only, essentially sending his email to another address entirely. Spammers strip the “+” and whatever follows it, so the spam ends up at the same address.
If spammers are converting from `[email protected]` to `[email protected]`, they are welcome to spam it as much as they want - it won't get to me.
EDIT: moreover, a service is perfectly within their rights to _internally_ store my email as `[email protected]` if they want - but they should still accept `[email protected]` as the identifier used to login with.
I’ve seen sites send emails where the unsubscribe link doesn’t work because the URL contains the email address I signed up with and that email address contains a character that their web server doesn’t play well with.
Interesting. How did that work? Does that mean that they would only create the user account under the + suffix? I imagine they must have had two email fields - the canonical email for login and then a separate notification email?