• must_be_fst (unregistered)

    /f..st/

  • MightyM (unregistered)

    [Insert "two problems" quote here]

  • Paul Tomblin (unregistered)

    Am I reading this right? If I typed my email address as ".@.", could I have logged in as anybody?

  • (cs) in reply to Paul Tomblin
    Paul Tomblin:
    Am I reading this right? If I typed my email address as ".*@.*", could I have logged in as anybody?
    .* would have sufficed, but perhaps the system doesn't like more than one match.
  • Ron (unregistered)

    You'd probably still needed the right password though

  • Phil (unregistered) in reply to Ron

    a right password...

  • (cs) in reply to TGV
    TGV:
    Paul Tomblin:
    Am I reading this right? If I typed my email address as ".*@.*", could I have logged in as anybody?
    .* would have sufficed, but perhaps the system doesn't like more than one match.
    the system only uses the first match
  • Black Bart (unregistered)

    I was expecting the callback saying that no logins were working due to their storage of the previously regex'd email address as a key.

  • anonymous (unregistered)

    TRWTF is using regular expression to check email (which is used as username), which exact match is obviously expected. Why not using simple equality comparision?

  • Geoff (unregistered) in reply to anonymous

    Strictly speaking [email protected] and [email protected] are different address. Almost every mail delivery agent I have ever worked with treats them as the same but the specifications really do call for treating the mailbox part of the address as a label; and the MTAs largely get it right.

    Using a simple equality check where e-mail address are being utilized as user names is probably the most correct because when both [email protected] and [email protected] try and sign up for your service they are going to be very frustrated, but then if you don't at least ucase() when the thousands [email protected] type address users attempt to login as [email protected] they are going to be similar frustrated. Wrong though they may be, their numbers are greater; so when management gets the "bug" reports they are going to win.

    All in all regex is probably not the way to do it but you do need to tolerate some address mugging.

  • RFoxmich (unregistered) in reply to anonymous
    anonymous:
    TRWTF is using regular expression to check email (which is used as username), which exact match is obviously expected. Why not using simple equality comparision?

    That and "Wait, no, I want it back!" she said. "I make so many typos using that form, it was saving me so much time!"

  • Palad1 (unregistered)

    If only there was a way to check for string equality without case-sensitivity in .Net...

  • anonymous (unregistered) in reply to Geoff
    Geoff:
    Strictly speaking [email protected] and [email protected] are different address.

    To add complication, user@example and [email protected] is equal - the domain part is case non-sensitive.

    According to RFC, DNS is case-insensitive...

  • anonymous (unregistered)

    case non-sensitive -> case-insensitive...

  • anonymous (unregistered) in reply to Palad1

    Just convert both strings to all upper/lower case and check...

  • anonymous (unregistered) in reply to Palad1
    Palad1:
    If only there was a way to check for string equality without case-sensitivity in .Net...

    Just convert both strings to all upper/lower case and check...

  • faoileag (unregistered) in reply to Ron
    Ron:
    You'd probably still needed /(a)|(the)/ right password though
    The article doesn't mention a password. And looking at 
    public virtual User LoadByEmail
    neither does the code.

    Nice one, that one... hmmm... will Google Mail and others treat betty.booth and betty_booth as two different accounts, or will they stick to just one allowed separator?

  • (cs) in reply to RFoxmich
    RFoxmich:
    anonymous:
    TRWTF is ...
    That and "Wait, no, I want it back!" she said. "I make so many typos using that form, it was saving me so much time!"
    That's blatant nonsense added to pad out the story, so it doesn't count.
  • (cs) in reply to anonymous
    anonymous:
    Palad1:
    If only there was a way to check for string equality without case-sensitivity in .Net...
    Just convert both strings to all upper/lower case and check...
    OMG Ponies!!! (Aka Humanity: Epic Fail): Classic text that explains (among other issues) why "simple straightforward" ideas like this fail in practice.

    And fail here means support call, your code passed lots of tests but doesn't work in production!

  • (cs) in reply to faoileag
    faoileag:
    Ron:
    You'd probably still needed /(a)|(the)/ right password though
    The article doesn't mention a password. And looking at 
    public virtual User LoadByEmail
    neither does the code.
    The code can still go like this: 
    User u = LoadByEmail(addr);
if(u.passHash == PasswordSecureHashOhWhoAmIKiddingItsJustGetHashCode(passwd))
{ ... }
  • Snowman25 (unregistered) in reply to Paul Tomblin

    Most probably as the first user in the database which matches your password-hash

  • foo AKA fooo (unregistered) in reply to pjt33
    pjt33:
    RFoxmich:
    anonymous:
    TRWTF is ...
    That and "Wait, no, I want it back!" she said. "I make so many typos using that form, it was saving me so much time!"
    That's blatant nonsense added to pad out the story, so it doesn't count.
    It's obviously fictional, but it's short and to the point, without introducing redundant characters, obscure quotes and long filler text. To me that's an acceptable level of creative writing (provided the rest of the story is real).
  • Kevin (unregistered) in reply to anonymous
    anonymous:
    Palad1:
    If only there was a way to check for string equality without case-sensitivity in .Net...

    Just convert both strings to all upper/lower case and check...

    I believe his point was their IS a way of ignoring case in .net... StringComparison.InvariantCultureIgnoreCase

  • Sean (unregistered) in reply to RFoxmich
    RFoxmich:
    anonymous:
    TRWTF is using regular expression to check email (which is used as username), which exact match is obviously expected. Why not using simple equality comparision?

    That and "Wait, no, I want it back!" she said. "I make so many typos using that form, it was saving me so much time!"

    Not to mention <snarky_tech>"Then I suggest you make a second account," he said, "with an address you can actually type."</snarky_tech>

  • Ed (unregistered)

    Why would you SQL escape what is obviously a MongoDB query?

  • (cs) in reply to Sean
    Sean:
    Not to mention <snarky_tech>"Then I suggest you make a second account," he said, "with an address you can actually type."</snarky_tech>
    When I saw that, I thought of those things we all **want** to say to pebkac users. Fortunately for our continued employment, we either think better of it before engaging mouth and/or send button, or we are too afraid of (something or other) to actually do it.

    And on the question of distinctness of email addresses, don't forget that the hypothetical addresses [email protected], [email protected], and even [email protected] are all the same even if they look different. (GMail has a substantial quantity of WTFs, and this is just one of them. Most parts of the GUI are epically WTF, as is their policy of dropping parts that actually work in favour of "simplifications" that make it harder to use. Like when they dropped a perfectly normal scroll bar on the "contacts" pane in favour of one that appears only when (i) the number of contacts warrants a scroll bar(*) and simultaneously (ii) the cursor is over the contacts pane. So until you point the cursor at the contacts pane, you think half your contacts are missing.

    (*) Scroll bars that disappear completely when there isn't a scrollable amount of stuff are a minor WTF in themselves because you cannot tell that the application/webpage/whatever allows more stuff than that. Compared to the onhover appearance not-onhover disappearance of GMail's scrollbars, however it's nothing more than a minor nuisance. Windows 8's never-marked hot corners are worse, however.

  • Tale (unregistered)

    It's a good thing their registration system probably rejected email addresses with "+" in them.

    No wait, I mean the opposite. It's a terrible thing that their registration system probably rejected perfectly valid email addresses like so many others do.

  • Justsomedudette (unregistered) in reply to no laughing matter
    no laughing matter:
    anonymous:
    Palad1:
    If only there was a way to check for string equality without case-sensitivity in .Net...
    Just convert both strings to all upper/lower case and check...
    OMG Ponies!!! (Aka Humanity: Epic Fail): Classic text that explains (among other issues) why "simple straightforward" ideas like this fail in practice.

    And fail here means support call, your code passed lots of tests but doesn't work in production!

    I just watched the video - it was really interesting and entertaining, thank you.

  • --- (unregistered) in reply to Phil

    You´d need the right password since account name and passwords are paired

  • bob (unregistered) in reply to no laughing matter

    Because of Turkish uppercase 'i' ?

    so string.toLowerCase() then?

    There I fixed it.

  • AP² (unregistered) in reply to faoileag

    Gmail will treat betty_booth as a different address, but bettybooth == betty.booth == b.e.t.t.y.b.o.o.t.h.

    That is, dots are ignored.

  • JAPH (unregistered) in reply to faoileag
    faoileag:
    Nice one, that one... hmmm... will Google Mail and others treat betty.booth and betty_booth as two different accounts, or will they stick to just one allowed separator?

    GMail ignores periods and capitalization for the local part (not to mention anything after the plus symbol); However, most other Google applications treat periods as significant characters.

  • Anon (unregistered)

    TRWTF is that some of the commenters still think it is OK to "validate" email addresses.

    It hasn't been OK, nor has it been POSSIBLE, to "validate" email addresses for a decade, why are you still trying?

  • Herr Otto Flick (unregistered) in reply to Anon
    Anon:
    TRWTF is that some of the commenters still think it is OK to "validate" email addresses.

    It hasn't been OK, nor has it been POSSIBLE, to "validate" email addresses for a decade, why are you still trying?

    Utter bollocks, email addresses are trivial to validate.

    1. Send an email to the email address with a secret token inside
    2. ask user to supply token
    3. Validated email address

    Moron

  • Tux "Tuxedo" Penguin (unregistered) in reply to anonymous
    anonymous:
    TRWTF is using regular expression to check email (which is used as username), which exact match is obviously expected. Why not using simple equality comparision?

    Maybe company in question is Google and as you know gmail has this little feature regarding + character (and I'm not talking about G+)

  • topj (unregistered)

    uh, isn't Antoine a man's name?

    (Captcha: "transverbero" ... appropriate)

  • (cs) in reply to Anon
    Anon:
    TRWTF is that some of the commenters still think it is OK to "validate" email addresses.

    It hasn't been OK, nor has it been POSSIBLE, to "validate" email addresses for a decade, why are you still trying?

    Rather longer than a decade, I'd say (most of the complicated rules about email addresses date back to the era of RFC 822, which is over thirty years ago).

    And presumably by "validate" you mean "decide by inspection that it has syntactic correctness". It is possible to do this, but (i) not worth the effort compared to just sending a email with an "activate" link and (ii) not as functional as just sending that email.

    Sending that email to the putative address confirms that not only does the address match syntactic correctness (or at least sufficiency) but also that it is for the right mailbox. In effect, it guards against fumble-fingered pebkac (and other) users and malicious hofnofs who type in other people's email addresses to subscribe them to nasty stuff.

    There are reasons, by the way, why the activation link should have a reasonably long expiry time (measured in hours, maybe up to a couple of days), mostly related to signups where the user doesn't have easy access to e.g. a work email account while he is not in the office, or an ISP-hosted email account while he is in the office.

  • topj (unregistered) in reply to topj

    dammit, ignore - the customer's the one doing the talking

  • (cs) in reply to topj
    topj:
    uh, isn't Antoine a man's name?

    (Captcha: "transverbero" ... appropriate)

    It is, and if you read more carefully you'll see that "he" refers to Antoine while "she" refers to the pebkac user.

  • Shill (unregistered)

    I thought for sure the WTF was going to be that they were using LIKE in their database query causing the underscore in the correct email to act like a wildcard. Silly me - instead they made the . act like a wildcard by unnecessarily introducing regular expressions. Obviously I'm not thinking big enough with these WTFs.

  • JA (unregistered)

    The WTFness of this article is healthy.

    I like the way TDWTF is going this last couple of weeks - it was getting pretty bad beforehand with the not-so-wtfs remixed into sensationalism-and-not-so-wtfs.

    Captcha: populus (n) - A sexually-transmitted infection caught by listening to annoying music, drinking fizzy drinks and spending the night with a girl who was designated 'popular' at highschool - in that exact order.

  • Anon (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Anon:
    TRWTF is that some of the commenters still think it is OK to "validate" email addresses.

    It hasn't been OK, nor has it been POSSIBLE, to "validate" email addresses for a decade, why are you still trying?

    Rather longer than a decade, I'd say (most of the complicated rules about email addresses date back to the era of RFC 822, which is over thirty years ago).

    And presumably by "validate" you mean "decide by inspection that it has syntactic correctness". It is possible to do this, but (i) not worth the effort compared to just sending a email with an "activate" link and (ii) not as functional as just sending that email.

    Sending that email to the putative address confirms that not only does the address match syntactic correctness (or at least sufficiency) but also that it is for the right mailbox. In effect, it guards against fumble-fingered pebkac (and other) users and malicious hofnofs who type in other people's email addresses to subscribe them to nasty stuff.

    There are reasons, by the way, why the activation link should have a reasonably long expiry time (measured in hours, maybe up to a couple of days), mostly related to signups where the user doesn't have easy access to e.g. a work email account while he is not in the office, or an ISP-hosted email account while he is in the office.

    VALIDATION is determining that it is possible for an address to exist. It is impossible to validate an email address, especially when dealing with Unicode addresses. You have no way to know what characters the target domain may or may not allow in the Local.

    VERIFICATION is determining that the email address is accurate. It is impossible to determine that an email address is accurate without human intervention, such as a verification link. You have no way to know what processing the target domain may perform on incoming mail.

  • (cs) in reply to Herr Otto Flick
    Herr Otto Flick:
    Anon:
    TRWTF is that some of the commenters still think it is OK to "validate" email addresses.

    It hasn't been OK, nor has it been POSSIBLE, to "validate" email addresses for a decade, why are you still trying?

    Utter bollocks, email addresses are trivial to validate.

    1. Send an email to the email address with a secret token inside
    2. ask user to supply token
    3. Validated email address

    Moron

    Except that it's not all that hard to hijack the recipient email address in many cases. Some enterprising fellow grabbed some yahoo-mail addresses which had been allowed to expire, BUT which were still the "backup verification" address and semi-abandoned secondary sites. By getting the old "forgot my password" message emailed to the yahoo addresses, he took over other domain accesses from the true owner.

  • (cs) in reply to Anon
    Anon:
    TRWTF is that some of the commenters still think it is OK to "validate" email addresses.

    It hasn't been OK, nor has it been POSSIBLE, to "validate" email addresses for a decade, why are you still trying?

    Oh, come on. It can't be much harder than parsing HTML with a regex. Just give it a try.

  • digisky (unregistered)

    Personally on the client side I just check for the @, a length > 3 characters, and at least 1 character on each side of the @. It may not be 100% foolproof but works in every case I've come across.

  • foo AKA fooo (unregistered) in reply to digisky
    digisky:
    Personally on the client side I just check for the @, a length > 3 characters, and at least 1 character on each side of the @. It may not be 100% foolproof but works in every case I've come across.
    So you accept ab@c and a@cd, but not a@c. Any particular reason for that?

    (IOW you check for /.@..|..@./ -- why not just /.@./ then?)

  • luptatum (unregistered) in reply to Anon
    Anon:
    VALIDATION is determining that it is possible for an address to exist. It is impossible to validate an email address, especially when dealing with Unicode addresses. You have no way to know what characters the target domain may or may not allow in the Local.
    Where did this magic requirement come from - "you have to check whether the domain would accept the local part as a valid account name, assuming their current software and policies, if someone tried to register it"? Any non-insane person would take "validation" to mean "checking that it's syntactically valid according to the generally accepted standards".
  • (cs) in reply to bob
    bob:
    Because of Turkish uppercase 'i' ?

    so string.toLowerCase() then?

    There I fixed it.

    Well you are obviously joking, but in case anyone takes this seriously, a comment from the article linked above:
    Visual Studio fails the Turkey test as well. On a Turkish locale, when you drag a component starting with the letter "I" on to your form, the form designer converts the component name to lowerCamelCase. An instance of ImageList for example becomes ımageList. Your code will compile fine on Turkish locale computers. Now try sending the code to someone with a non Turkish locale...
  • (cs) in reply to no laughing matter
    no laughing matter:
    OMG Ponies!!! (Aka Humanity: Epic Fail): Classic text that explains (among other issues) why "simple straightforward" ideas like this fail in practice.

    And fail here means support call, your code passed lots of tests but doesn't work in production!

    That was a fun read. On a similar tack, there is "Falsehoods Programmers Believe About Names" at [url=http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/].

    Sincerely,

    Gene Wirchenko

  • Anon (unregistered) in reply to luptatum
    luptatum:
    Anon:
    VALIDATION is determining that it is possible for an address to exist. It is impossible to validate an email address, especially when dealing with Unicode addresses. You have no way to know what characters the target domain may or may not allow in the Local.
    Where did this magic requirement come from - "you have to check whether the domain would accept the local part as a valid account name, assuming their current software and policies, if someone tried to register it"? Any non-insane person would take "validation" to mean "checking that it's syntactically valid according to the generally accepted standards".

    Which of the standards? The outdated ASCII standard, or the current Unicode one? I've never encountered a validation that even works for the first one, which is ridiculously simple, let alone the second, which is geometrically more difficult.

Leave a comment on “Universal Login System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article