Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Correct Way to Validate Email Addresses

hackernoon.com

Post reply on HN
Print view View original

211–220 of 405 posts

Re: The Correct Way to Validate Email Addresses

#211

Post by flukus »

Hydraulix989 wrote: post #193
ryandrake wrote: post #35

Earlier quoted context omitted.

Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...

Even Linux tools like GNOME Archive Manager in Linux Mint 18 rejected my RAR password containing a $ as the incorrect password, even though it was the correct password for the RAR file I was trying to extract. I then used the command-line unrar utility with the exact same password, and it extracted successfully. Now, why would you preemptively (and explicitly) throw out a candidate password string based on its charac…

I'm guessing both are because the are calling command line tools. One of my pet peeves with linux is that many of these tools are only callable via text and don't expose an API for other programs.

Re: The Correct Way to Validate Email Addresses

#212

Post by vacri »

zAy0LfpBZLC8mAC wrote: post #75
vacri wrote: post #74

Earlier quoted context omitted.

email addresses for usernames have the advantage of already being unique. None of this "gregmac already taken, try gregmac23, gregmc_595, or verbingnounXX instead?" nonsense

> email addresses for usernames have the advantage of already being unique Not true. There are people who share an email address.

I mean unique as far as your end is concerned. Short of very invasive technology, there's no way to stop people from sharing a user token if they choose to do so.

Re: The Correct Way to Validate Email Addresses

#213

Post by flukus »

userbinator wrote: post #130
usaphp wrote: post #48

Earlier quoted context omitted.

Or when a password that is generated by my password manager is rejected with a message "Password should be 12 characters maximum". Why???

Even 15, 16, 31, or 32 (all of which I've seen before) would make more sense. 12 is "odd".

Unless they are trying to pack multiples of 2 at a row level. It's 12 so the can squeeze a char(2) somewhere else.

Re: The Correct Way to Validate Email Addresses

#214

Post by RobertKerans »

danneu wrote: post #140
mschuster91 wrote: post #115

Earlier quoted context omitted.

Yes. OS X keyboard drives me nuts sometimes, Karabiner can only fix some bits of the weirdness.

option-e and then a vowel will create {á é í ó ú} option-u and then a vowel will create {ä ë ï ö ü ÿ} option-n and then an 'n' will create ñ Found this out while learning Spanish since holding down keys to select their alternate was way too slow.

Thank you, this was driving me nuts.

Re: The Correct Way to Validate Email Addresses

#215

Post by vacri »

mabcat wrote: post #183
niij wrote: post #164

Earlier quoted context omitted.

Care to expand? As in having a first.last@example versus firstlast@example

As in bloggsfamily@localisp.net.au that both parents and all the younger sprogs share. Still common as anything.

One of the things I loved about the original Mad Max film was that they nicknamed their own toddler 'Sprog'...

Re: The Correct Way to Validate Email Addresses

#216

Post by vacri »

gregmac wrote: post #80
vacri wrote: post #74

Earlier quoted context omitted.

email addresses for usernames have the advantage of already being unique. None of this "gregmac already taken, try gregmac23, gregmc_595, or verbingnounXX instead?" nonsense

I agree, but in that case, you should be validating the e-mail address (which was my original point). Failure to do so means: - The user who actually owns that e-mail can't login - The user who signs up can potentially impersonate the real user (depending on what your app does) - The user who signs up can't reset their password - The user who actually owns the e-mail can take ownership of the account (by resetting pa…

Fair points.

One argument against emails-as-names is that some people change email addresses frequently - unless you have some way of accounting for that (and you definitely wouldn't use the username as the contact field), the username will eventually go stale for some users.

Re: The Correct Way to Validate Email Addresses

#217

Post by mnkypete »

bbcbasic wrote: post #169
DHowett wrote: post #131

Earlier quoted context omitted.

a@[IPv6:2001::1] is, unfortunately for your validation regex, a valid e-mail address. [EDIT: I see that you consider TLD-free e-mail addresses undeliverable; still!]

.+@.+ FTW?

That's what we do. Everything else is just lying to yourself and hoping for the best..

Re: The Correct Way to Validate Email Addresses

#219

Post by sigi45 »

His number is probably wrong. I personally wrote/typed my email address wrong (when you have those two fields).

There are also common pitfalls people are doing like empty spaces at the beginning and at the end which should be cleaned up before trying to send the email to " whoever@gmail.com".

There is also an Email standard and when a normal library is able to validate it (and there are free good libs out there) than the effort to do so is similiar minimal but provides an additional support.

What you should do is also to make sure that you are not sending unlimited emails out there. Otherwise you might be missused as a mail relay / spammer.

Re: The Correct Way to Validate Email Addresses

#220

Post by viraptor »

pwg wrote: post #61
ryandrake wrote: post #35

Earlier quoted context omitted.

Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...

Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. Why: Because if they were (at least) hashing it the output from the hash would be a binary string in which case they would have to be 8-bit clean through to the DB column where the hash output resided, and then there wou…

As much as I agree that most artificial limits on the passwords are silly, there's a reason for at least limiting to latin1 charset - or maybe even a bit stricter. How sure are you that strings are always unified the same way between the browser and hashing? Have you tested that you can login from a browser which prefers CJK encodings and each of the UTFs? From all browsers? Maybe it works, maybe your framework deals with this without issues. But if not, do you really want to chase those mysteries in the future?

Btw, almost nobody is actually storing hashes as binary blobs. Pretty much every framework I know stores either base64, or direct hex encoding of the value.

Post reply on HN