3 ms·

So, people have blamed the vendor's API... but have they opened a ticket with them, raised the issue, escalated it? I can emphasize with not wanting to work ar

So, people have blamed the vendor's API... but have they opened a ticket with them, raised the issue, escalated it? I can emphasize with not wanting to work around the bugs of an upstream provider, but just sitting on it when it causes real pain to customers is also shitty. > That's right, for any developer, the answer here is simple: use the coupons that we are ALREADY receiving on the frontend to populate the fields that users expect so they can get their discounts. Hard to tell without knowing more details, but that might run into the risk that people can inject made-up discounts in the browser and send them to the backend, which then charges less.

beezlewax 3y ago
Sounds like that to me too. I'm sure there is more going on there though
doix 3y ago
> Hard to tell without knowing more details, but that might run into the risk that people can inject made-up discounts in the browser and send them to the backend, which then charges less. That was my first thought, but thinking about it more, it probably makes no difference. If it's susceptible to injected made-up discounts now, it would have been susceptible before as well. It doesn't matter if the coupon code comes from the vendor API or their own API if you're going to inject fake data anyway.
javier123454321 3y ago
I'm not privy to the extent of the conversations with the vendor, I came in with fresh eyes and found a solution. The writeup was just musing on the process that let it get to that point from my perspective. Your final issue is not a risk in this case, because we still are validating the coupons. This was a frontend fix, and we obviously don't trust any data coming from the frontend.
Nemi 3y ago
Here’s the deal, at two years and for a problem that is by all accounts serious, any solution is better than no solution. Now, if this is code that runs ventilators for sick people, runs the movement of money for a hedge fund, or balances the US budget, then no, you have to be absolutely, positively sure that you are not causing another problem. But when you have a real problem that is affecting people everyday for years, then a little creativity is certainly called for. Even at the expense of hypothetically causing another problem.

beezlewax 3y ago

Sounds like that to me too. I'm sure there is more going on there though

doix 3y ago

> Hard to tell without knowing more details, but that might run into the risk that people can inject made-up discounts in the browser and send them to the backend, which then charges less. That was my first thought, but thinking about it more, it probably makes no difference. If it's susceptible to injected made-up discounts now, it would have been susceptible before as well. It doesn't matter if the coupon code comes from the vendor API or their own API if you're going to inject fake data anyway.

javier123454321 3y ago

I'm not privy to the extent of the conversations with the vendor, I came in with fresh eyes and found a solution. The writeup was just musing on the process that let it get to that point from my perspective. Your final issue is not a risk in this case, because we still are validating the coupons. This was a frontend fix, and we obviously don't trust any data coming from the frontend.

Nemi 3y ago

Here’s the deal, at two years and for a problem that is by all accounts serious, any solution is better than no solution. Now, if this is code that runs ventilators for sick people, runs the movement of money for a hedge fund, or balances the US budget, then no, you have to be absolutely, positively sure that you are not causing another problem. But when you have a real problem that is affecting people everyday for years, then a little creativity is certainly called for. Even at the expense of hypothetically causing another problem.