Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A routine gem update ended up creating $73k worth of subscriptions

serpapi.com

Post reply on HN
Print view View original

61–70 of 336 posts

Re: A routine gem update ended up creating $73k worth of subscriptions

#61

Post by cirrus3 »

> In Mongoid (The MongoDB driver for Ruby) 7.0.8 , or() meant filter documents that contain any of the argument conditions.

> In Mongoid 7.3.3 , or() now means filter documents that contain any of the argument conditions OR any of previous method conditions

It actually sounds like they "fixed" it to work the way you'd expect... but changing an API like this one in this way is extremely dangerous.

I wouldn't call what you have a code smell, you coded it correctly according to the Mongoid API at the time.

Mongoid is at fault here. An API that changes the behavior of a function are core as "or()" in this way is pure insanity - even if they were trying to make it do what it really should have in the first place, or if it were a major version, and they documented it well.

Note to self - avoid Mongoid.

Re: A routine gem update ended up creating $73k worth of subscriptions

#62

Post by gruez »

seanwilson wrote: post #39

> SerpAPI: Scrape Google and other search engines from our fast, easy, and complete API. Does anyone know how this works behind the scenes at scale? How do they get around Google trying to stop their scraping attempts? Just lots of proxies and some way around captcha challenges?

probably a combination of realistic-seeming desktop browsers (eg. headless chrome with stealth patches) and residential IP providers (eg. luminati)

Re: A routine gem update ended up creating $73k worth of subscriptions

#64

Post by rsynnott »

ricardobeat wrote: post #24
BlackFingolfin wrote: post #20

Earlier quoted context omitted.

To be fair, the your second link points to the documentation of an ancient version; the new docs don't seem to mention semver (I still don't think what they are doing is reasonable, but ...)

That link is reachable from their home page right now, under “Upgrading”. EDIT: just noticed the docs I found via Google are marked as “old” in the URL: https://mongoid.github.io/old/en/mongoid/ Are you suggesting they dropped semver in between these releases?

> Are you suggesting they dropped semver in between these releases?

If this is the case, I kind of hope, for maximum irony, that they dropped it as part of a minor version bump.

Re: A routine gem update ended up creating $73k worth of subscriptions

#65

Post by cirrus3 »

booleanbetrayal wrote: post #54

So ultimately this is the result of someone not actually reading through the changelog notes from over a year+ of iteration? I guess you can be annoyed with a third-party's abuse of SemVer, but practically everybody abuses those conventions and any developer who is versed in dependency management should have known better than to not read over changelogs. Likewise, any reviewer should have caught this.

It is... but it is also a result of a library changing the meaning of "or". This is next-level breaking change that is beyond what I'd even call a "change".

Re: A routine gem update ended up creating $73k worth of subscriptions

#66

Post by MBCook »

avianlyric wrote: post #56
denotational wrote: post #28

> Our app for some reasons was creating new subscriptions from old accounts that was canceled or disabled a long time ago. If I cancel or disable my account for a service I don't expect them to be able to charge me money in the first place! Are they keeping card authorisations (or direct debit mandates, or whatever other mechanism) for customers that don't even have an account with them any more? That sounds like an.…

They don’t need to keep anything. The card details will be stored with Stripe, if they don’t actively tell Stripe to delete those details then they’ll be able to create a new subscription and charge the card. For the vast majority of cases all you need to charge a card is the 16 digit number on the front and an expiry date. Pretty much everything else is optional (CVV, Name, Address etc), but opens you up to stupid l…

Agreed. I’d go as far as to say they were irresponsible to not tell Stripe to delete/deauthorize the tokens.

In fact, why does any customer in their database have ANY connection to Stripe after they’ve canceled? I haven’t used stripe but I’m guessing there’s some sort of customer ID/token. If they’ve canceled why are you retaining that?

So that’s two things. Even if the code encountered a bug like they did here, it shouldn’t of been possible to actually trigger a new subscription.

Re: A routine gem update ended up creating $73k worth of subscriptions

#67

Post by kingcharles »

gruez wrote: post #62
seanwilson wrote: post #39

> SerpAPI: Scrape Google and other search engines from our fast, easy, and complete API. Does anyone know how this works behind the scenes at scale? How do they get around Google trying to stop their scraping attempts? Just lots of proxies and some way around captcha challenges?

probably a combination of realistic-seeming desktop browsers (eg. headless chrome with stealth patches) and residential IP providers (eg. luminati)

Yep. Has to be using a large net of residential addresses in each country to not get banned by Google.

Re: A routine gem update ended up creating $73k worth of subscriptions

#68

Post by victor9000 »

josefx wrote: post #53
mushufasa wrote: post #18

Of note -- their company services seem to be that you pay them to return you Google search results via API. Isn't that against the Google search Terms of Service??? If google wanted there to be a paid search api, I'm pretty sure they would just provide one. Also, I'm pretty sure I've seen these types of startups before, and then they vanish quickly thereafter....

What do you even call it when the biggest web scraper of the world prohibits web scraping in its terms of service?

Hypocrisy that is borderline unethical.

Re: A routine gem update ended up creating $73k worth of subscriptions

#69

Post by FanaHOVA »

denotational wrote: post #28

> Our app for some reasons was creating new subscriptions from old accounts that was canceled or disabled a long time ago. If I cancel or disable my account for a service I don't expect them to be able to charge me money in the first place! Are they keeping card authorisations (or direct debit mandates, or whatever other mechanism) for customers that don't even have an account with them any more? That sounds like an.…

The Ruby 1.9 hash syntax was the first red flag honestly... :P
Post reply on HN