381–390 of 405 posts
At this point, our email validity criteria: .+@.+\..{2,} That is, at least one character for the inbox, at least one character for the domain, at least two for the TLD (we assume that TLD-less domains are undeliverable by us). This ensures we don't allow 'a@a' or 'a@a.a', but do allow 'a@a.io'.
The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)
Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for examp…
> Sure, the complete regex is complex, but it is defined and is hardly unconquerable. If it is a regular expression, then it is not able to match all valid email addresses, because the grammar of email addresses is context-free, and regular expressions can only match regular grammars. It doesn't matter if it is defined or not: if it's a true regular expression, then it simply cannot validate email addresses. (it may,…
2. Remove everything between + and @
3. Do validation
Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for examp…
Regarding that testdata, what is the reason for rejecting bare IP literals on the right hand side? It seems pedantic to require the square braces.
Earlier quoted context omitted.
Address validation by sending an email should only be used if it is required for some reason to verify the user owns the email account. Otherwise, it's not a great UX.
I honestly can't think of a reason you'd ask a user for their email but not need to validate it. For being able to do password resets later, permission to add to mailing list, avoiding sending private info to the wrong user, avoiding allowing someone to masquerading or impersonate someone they're not.. All should be validated. If you're looking for a username as login identity and nothing more (and you don't have pas…
Mailing list - reluctant OK
"avoiding sending private info to the wrong user" - how could this happen?
"avoiding allowing someone to masquerading or impersonate someone they're not" - how could this happen? Like if I signed up as tim@apple.com? What could realistically happen?
1: Does it have an @ 2: Is it at least 5 chars long (E.g. a@b.c)
Earlier quoted context omitted.
"callable via text"? What does that even mean? The command line is an API, isn't it? If people don't manage to pass an ampersand to another program via the command line, that's really no different than people failing to pass an ampersand as a URI parameter to an HTTP resource: Failure to encode properly. There is absolutely nothing that prevents you from passing an ampersand (or any other characters) to a program via…
> "callable via text"? What does that even mean? It means you have to execute commands through a shell. A real API would be something you could include in your program, execute a method against and get a list of objects back. Instead all these basic command are replicated in every framework. As far as encoding properly, you're preaching to the choir, but out in the real world there is still injection attacks everywhe…
Except you don't. There is no need to involve a shell.
> A real API would be something you could include in your program, execute a method against and get a list of objects back.
So, Web APIs are not APIs?
Also, you can execute methods against command line programs, method names usually start with a dash.
Earlier quoted context omitted.
My bank limits passwords at 15 characters. The best thing? There is no verification, it just cuts off. Have fun figuring out why you can not login anymore.
My bank limits passwords to ten chars. Ten! Have you ever heard any reasoning behind why they do this? The "best" excuse I've heard is so that customers don't forget. As if they don't have a "Forgot password?" link right there .