Google Play In-App Billing Server Purchase Verification

220px-Wutangclanprotectyaneck

My current project, PrēmoFM will feature In-App Billing.  I’ve successfully implemented Google Play In-App Billing v3, leaning a lot on the demo available at developer.android.com.  One major fallback of the example provided is on-device purchase verification (Google themselves recommend against on device purchase verification).  No matter how hard you try, Android apps are easily reverse engineered, allowing hackers to compromise your purchase verification logic.  They could spoof purchase interactions and gain access to IAB protected content and features for free.

I implemented my purchase verification using my Node.js-based API server.  When purchase data is returned from Google Play, I send it to my API server for immediate verification.  Once it’s been verified (or not) a response is sent back to the app, unlocking the content or feature.  Here is, more or less, how I verify purchases in Node.js.  It uses Node.js crypto library.

 

PHP

 

Screenshot from 2015-06-09 18:51:28

I can’t believe I was about to take the time to contribute another negative article to the Internet about PHP.  Instead of spending any more time on it, I’ll just leave this here.

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make itcompletely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

–> PHP: a fractal of bad design

Building Software That Scales

53646549

It’s been a long time since I’ve posted here.  I’ve been really busy in general, but I’m excited to publish this post (I actually forced myself to publish this post).

Over the past few weeks, since I returned from vacation, I’ve been working on building a backend that scales.  I’m building an Android podcast app, PrēmoFM.  My podcast app needs a backend parsing infrastructure that scales to parse hundreds of thousands of podcast XML files constantly.  As I type this, I’m about to unleash hundreds of thousands of podcast channels onto my beta users.  Up to this point, they’ve only had access to 75, which mostly consisted of my favorite podcasts.  That number will be increasing to north of 200,000.  I’m ecstatic about this because these are the first pieces of software that I built that operates at this scale.

In order to provide a good user experience to PrēmoFM users, I need to be able to parse at least 5,000 podcasts per minute.  On the surface, this would allow me to run through the entire catalog one time in 40 minutes.  I’ve made several architectural decisions that allow me to achieve this.  I’ve built highly multi-threaded Java apps that serve a single purpose:

  • HTTP XML data retrievers
  • XML Parsers
  • Push message senders

Each portion of the chain has it owns challenges and constraints, so I needed to build apps that were focused in their function.  This also allows me to spin up instances of each app to keep my XML parsing pipeline saturated and operating at peak performance, which is exactly what I did.  Secondarily, I’m able to iterate and update each component separately.  I can only imagine the frustration if I had one Java app that did the retrieval, XML parsing, and push message sending.  I’m still doing to a bit of testing before I move everything up to my production VPSes (virtual private servers), but I’ve already blew past my baseline goal of 5,000 podcasts per minute and am peaking around 12,000+ (Update 5/25/2015 @ 1AM – deployed to DigitalOcean – peaking at 27,000 channels per min, bonkers, to me anyway), which is at least two orders of magnitude increase from where I was a week ago.  In fact, things are moving so fast, I’m going to have to significantly cut down on the logging or it’ll begin eating up all of the available hard drive space.

I’ll provide more detail on my backend architecture in the future, when I have time to document.  For right now, I’m marching towards release.

Are you an Android user?  Sign up for the beta at Prēmo.FM