solidus icon indicating copy to clipboard operation
solidus copied to clipboard

Order total upper limits are not validated

Open seand7565 opened this issue 4 years ago • 5 comments

Order totals are effectively limited to $100,000,000 because we're using precision 10 scale 2, which need to be less than 10^8 (100 million). However, this isn't validated anywhere, meaning that normal users can cause an ActiveRecord::RangeError whenever they want (if they're clever or products are priced high enough).

Not a big deal, but would be great to have one less error popping up in the logs!

To reproduce: Go here and change the price to $1,000 Then go here and add 1000000 to your cart.

That being said... I'm pretty sure this isn't a real issue for anyone, it just popped up in the demo error tracker and I thought it'd be best to create a corresponding issue. 🤷‍♂️

seand7565 avatar Dec 11 '20 21:12 seand7565

Id love to o see a store with this as a live issue On Fri, Dec 11, 2020 at 4:45 PM Sean Denny [email protected] wrote:

Order totals are effectively limited to $100,000,000 because we're using precision 10 scale 2, which need to be less than 10^8 (100 million). However, this isn't validated anywhere, meaning that normal users can cause an ActiveRecord::RangeError whenever they want (if they're clever or products are priced high enough).

Not a big deal, but would be great to have one less error popping up in the logs!

To reproduce: Go here http://demo.solidus.io/admin/products/ruby-mug/edit and change the price to $1,000 Then go here http://demo.solidus.io/products/ruby-mug and add 1000000 to your cart.

That being said... I'm pretty sure this isn't a real issue for anyone, it just popped up in the demo error tracker and I thought it'd be best to create a corresponding issue. 🤷‍♂️

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/solidusio/solidus/issues/3864, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZTL4ZUXCDNV7F7WR7GG3SUKHHXANCNFSM4UXJMETA .

dhonig avatar Dec 11 '20 21:12 dhonig

I'm sure in a few currencies it's conceivable.

jarednorman avatar Dec 16 '20 01:12 jarednorman

Hey @seand7565, thanks for raising this issue. I could reproduce this error on the demo store, but could not do it locally. Even managed to get order totals above 1 billion with no problem. Are you manage to reproduce it locally?

RyanofWoods avatar Jun 15 '21 07:06 RyanofWoods

@RyanofWoods It does not occur with SQLite3. I've only tested it with postgres (which is what the demo store runs on too) but I can get it to reproduce locally with pg.

seand7565 avatar Jun 15 '21 19:06 seand7565

@seand7565 oh of course! 😁 Thanks so much.

Looking at the database tables there are quite a few fields that have precision 10 scale 2. But many of them are related to total so this will be the first/main issue.

I think @jarednorman made a really good point 👍 . Looking at the 3 currencies with the lowest values these are the USD equivalents they would need to hit to break the store.

  1. IRR (2,375$)
  2. IDR (7,018$
  3. GNF (10,186$)

We could prevent the order total from becoming more than 100 million, which is much better than no patch But this could be bad user experience for a store selling expensive goods with IRR currency. (Saying that, this issue has never been raised by a low-value currency so far). The only other solution I can think of is to increase the precision, but that seems quite drastic, what do you think? 🤔

RyanofWoods avatar Jun 15 '21 20:06 RyanofWoods