Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Sunday September 22 2019, @08:23AM   Printer-friendly
from the testing-is-important dept.

Submitted via IRC for Bytram

The '$4.4m a year' bug: Chipotle online orders swallowed by JavaScript credit-card form blunder

Chipotle Mexican Grill has been leaving money on the table, thanks to an apparent bug in the restaurant chain's e-commerce operation.

On Thursday, Jason Grigsby, co-founder of app development biz Cloud Four, published his analysis of the eatery's online order form. The webpage code, he claims, contains an error that he estimates is costing the company millions in lost sales.

While attempting to submit an order, Grigsby encountered two error messages, one indicating that the website had been unable to save his credit card number – despite having not checked the box to allow this – and the other being a general submission error.

The errors happened every time he tried to use his browser's autofill capability but not when the data was entered manually. Upon further scrutiny, he noticed that his credit card's expiration date kept being changed after the date was filled in.

Grigsby traced the problem to the way the food biz implemented the expiration date input field in its order form. The order form, built using JavaScript with the Angular framework, relies on an Angular module called ui-mask, which allows developers to limit input based on a predetermined pattern.

In this case, the ui-mask="99" attribute limits the expiration date input field to two characters, but it provides the wrong ones. "When autofill tries to enter 2023, this ui-mask only lets the first two characters be entered," explains Grigsby.

By altering the credit-card expiration date, the form returns an error and prevents the order from going through. "I assume it is the backend processor rejecting the card because the expiration year is wrong [since] it happens after form submission," he explained in an email to The Register.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 3, Touché) by Rosco P. Coltrane on Sunday September 22 2019, @08:58AM (3 children)

    by Rosco P. Coltrane (4757) on Sunday September 22 2019, @08:58AM (#897052)

    Shitty food in, shitty code out...

    • (Score: 0) by Anonymous Coward on Sunday September 22 2019, @09:38AM (1 child)

      by Anonymous Coward on Sunday September 22 2019, @09:38AM (#897062)

      Programmer got e.coli and died mid-project.

      • (Score: 3, Funny) by chromas on Monday September 23 2019, @03:44AM

        by chromas (34) Subscriber Badge on Monday September 23 2019, @03:44AM (#897399) Journal

        e.coli? And here I am, still using angular.js! Always a new framework.

    • (Score: 1) by Ethanol-fueled on Sunday September 22 2019, @03:23PM

      by Ethanol-fueled (2792) on Sunday September 22 2019, @03:23PM (#897122) Homepage

      Hey, leave the Indian programmers out of this!

  • (Score: 1, Insightful) by Anonymous Coward on Sunday September 22 2019, @09:02AM (3 children)

    by Anonymous Coward on Sunday September 22 2019, @09:02AM (#897053)

    this case, the ui-mask="99" attribute limits the expiration date input field to two characters, but it provides the wrong ones. "When autofill tries to enter 2023, this ui-mask only lets the first two characters be entered,"

    So you mean when you want to enter 2023 and then it only allows you 2 digits, it's then the problem of the form not because the browser wants to stick in more digits?? Seems like your auto-fill is broken, not the form. The only bug here is that it's not complaining that the card was wrong.

    one indicating that the website had been unable to save his credit card number – despite having not checked the box to allow this

    That's a bug.

    • (Score: 3, Touché) by sjames on Sunday September 22 2019, @09:28AM (1 child)

      by sjames (2882) on Sunday September 22 2019, @09:28AM (#897060) Journal

      I guess it's up to Chipotle which is more important to them, being technically correct or an extra 4.4 million a year.

      • (Score: 0) by Anonymous Coward on Sunday September 22 2019, @10:06AM

        by Anonymous Coward on Sunday September 22 2019, @10:06AM (#897064)

        being technically correct or an extra 4.4 million a year.

        Where the $4.4m is a number that was pulled out of someone ass. Real number probably closer to $4k a year.

    • (Score: 2) by bradley13 on Monday September 23 2019, @04:38AM

      by bradley13 (3053) on Monday September 23 2019, @04:38AM (#897412) Homepage Journal

      I've had similar annoying bugs (features?) on other sites. Year must be 2 digits. No, year must be 4 digits. Month must be 2 digits, even if the first is a zero. Month must not have a preceding zero.

      Any of those restrictions indicate stupid UI design. Dates are a pain, and you UI code needs to deal with that, not force the user into a straight jacket.

      --
      Everyone is somebody else's weirdo.
  • (Score: 2) by bzipitidoo on Sunday September 22 2019, @12:56PM (3 children)

    by bzipitidoo (4388) on Sunday September 22 2019, @12:56PM (#897092) Journal

    Lot of Y2K bugs were caused by somewhere limiting the year to 2 digits. In the 1990s, limited memory was the lame excuse for that. 2 more digits might mean a whole extra byte of memory per date was needed. in a database containing 1 million rows, each with one date, that was a whole megabyte! And some management didn't want to spend the money to buy bigger hard drives.

    Now, with terabytes of storage capacity, that excuse is long expired. For this to be happening in 2019 is pitiful and embarrassing. I suspect only expiration years of 2020 worked. Maybe that one working year passed an inadequate unit test.

    I fixed one Y2Kbug that went from 1999 to 1910. Didn't have source code, had to disassemble the binary. How did it go wrong with the date? The program got the year, all 4 digits, subtracted 1900, and took the first two digits this operation produced. So, 2000-1900 = 100. That second zero overflowed the string buffer, causing another problem. I changed the code to do year mod 100, something that was possible to do in place by changing the assembler instructions, and that made it so 1999 was followed by 1900. Then I searched for and found where the program was tacking "19" on, and changed that to "20". I warned them that this would now mean 1999 was 2099, but they didn't care, didn't need 1999 any more and were very happy the 2000s were correct. Of course this means the program will break again in 2100. Maybe one of my grandkids can fix that one, in the unlikely event that that software is still in use.

    • (Score: 0) by Anonymous Coward on Sunday September 22 2019, @03:35PM

      by Anonymous Coward on Sunday September 22 2019, @03:35PM (#897127)

      In the 1990s, limited memory was the lame excuse for that. 2 more digits might mean a whole extra byte of memory per date was needed. in a database containing 1 million rows, each with one date, that was a whole megabyte! And some management didn't want to spend the money to buy bigger hard drives.

      That was the excuse that was trotted out in 1999 to explain the Y2K two digit year problem.

      But I very much suspect that this excuse was simply back-fit to the problem in 1999 and actually had zero bearing on the real reason why.

      What I very much suspect, if one could time travel back to when the two digit years were being written into programs, and ask why, that a different answer would be given, one more likely to sound a lot like: "that's how everyone does dates" or "no one will still be using this code in 30 years, so what is the problem?".

    • (Score: 2) by theluggage on Sunday September 22 2019, @03:58PM (1 child)

      by theluggage (1797) on Sunday September 22 2019, @03:58PM (#897136)

      Now, with terabytes of storage capacity, that excuse is long expired. For this to be happening in 2019 is pitiful and embarrassing.

      ...and if, in 2099, we're still using credit cards as we know it and but they have expiry dates more than 49 years in the future (well, there's bound to be some progress) then we'll only have ourselves to blame.

      Back in reality, there's no problem with saving typing by having a 2-digit year when you know that any valid date is going to (a) in the future and (b) less than 50 years in the future. Which is probably why most credit cards still use 2 digit dates... and GP is right - its hard to start anticipating what an Artificial Stupidity system like autofill (which probably picked up a 4-digit expiry date from another form with a 'select year' dropdown) will try and enter - and there's no way for a form to telepathically know that '20' isn't a valid expiry date until it actually submits the card for processing.

      Frankly, autofill is sometimes handy for addresses but shouldn't be touching credit card details anyway. I'm trying to think of a reason why we need to enter the expiry date for a card, esp. with the CVC serving as a double check, and the #1 reason that comes up is to remind the user to check the expiry date.

      That said... a good form should try its level best to be user friendly and accept any unambiguous input (and being able to accept either "2023" or "23" for an expiry date doesn't need AI) but that's in the realms of attention to detail - something to be picked up by user testing - not a 'bug'.
         

      • (Score: 2) by FatPhil on Monday September 23 2019, @11:26AM

        by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Monday September 23 2019, @11:26AM (#897506) Homepage
        card expiry dates shouldn't be more than a couple of years in the future, so a pull-down that contains this and the next few should be fine. We have a GUI, it's alright to use clicks to enter information into such interfaces nowadays.
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(1)