

Simple And Safe In-App Purchase Using Parse - andwang
http://blog.parse.com/2012/07/24/in-app-purchase/

======
nanijoe
If this is an App store gold rush, then Parse is truly positioning themselves
to sell the shovels

------
physcab
Have you tested whether this is effective in eliminating jailbroken hacks? [1]
In my experience, this has been the bulk of illegal transactions being made
for in app purchases and its tough to validate server-side. I agree though
that making the IAP process less complex is a win for developers.

[1] [http://blog.off-by-one.mobi/2009/10/in-app-purchase-and-
stat...](http://blog.off-by-one.mobi/2009/10/in-app-purchase-and-state-of-
iphone.html)

~~~
andwang
When one of my apps was pirated a few years ago, I became extremely interested
in iOS security. Based on my knowledge, I can vouch for the accuracy of the
article you linked to.

The article explains quite well what IAP makes secure and what it does not. If
you are using IAP to deliver content stored on Parse, Parse's SDK (and server
code) makes this process very secure. The attack goes like this:

1) the attacker fakes receipt and sends it to Parse hoping that Parse will
deliver the content, 2) Parse will send the receipt to Apple and ask if the
receipt is valid and indeed for the product that is being requested, 3) Apple
will acknowledge that this receipt is fake or for a product not being
required, 4) Parse rejects the request, and no content is delivered. Success.

However, if you are using IAP to unlock features that are already shipped with
the app, IAP does not prevent against binary manipulation attacks.

-Andrew

~~~
physcab
Awesome, in theory this is how it should work. I'm actually more curious as to
how you handle it practically though. Because for us, validating the receipt
from Apple takes time, so if you are first making a request to Parse and then
Parse has to make a request to Apple, the added latency poses a real threat to
the user cancelling the transaction, especially on a mobile device with a
crappy connection. This is why I see server-side validation as non-ideal. But
such is the state of mobile development.

~~~
idunno246
Most of the jail broken cracks are trivial to detect client side. Otherwise...
They aren't going to pay anyway, might as well make the experience better for
payers and not block on validation( but still track invalid transactions). And
besides, if they're willing to install a hackers DNS server and ssl cert, they
won't have money for long.

~~~
physcab
I agree. The hackers will only be a small percentage of your user base
(guessing <=5%), if you have a problem at all. This issue is more problematic
if you track revenue metrics, and so JB users may inflate your numbers
considerably, if you're not cognizant.

~~~
pooriaazimi
> _The hackers will only be a small percentage of your user base (guessing
> <=5%)_

Not if you're making a game for teenage boys.

------
MaxGabriel
Is anyone familiar with how this would compare to using iOS 6's IAP content-
hosting feature?

~~~
andwang
Officially we should not be commenting on iOS 6 given the non-disclosure
nature of the preview. Maybe I can discuss what Parse offers that would be
difficult for anyone else (Apple/Google/Amazon) to match:

1\. iOS 4, iOS 5 compatibility. Today, the most common iOS development target
platform is still iOS 4. Using Parse your in-app purchase will be able to work
for the customers who are not on the newest iOS platform.

2\. Attaching metadata for products. At Parse a lot of our customers want to
attach metadata information to products (categories, authors, genres, the
publishing date, actors, etc) and to query products based on this information.
You can imagine this is a very handy feature for an app that sells comic
books. This is very natural to do on Parse because Parse offers a query-able,
key-value data store. In fact, anyone, with or without technical background,
would be able to use the data browser to add the metadata to the Product
class.

3\. Hosting content on Parse requires no App Store review, thus introducing no
delay/resubmission via iTunes Connect.

4\. Hosting content on Parse has no limit on the number of files/total size of
files.

5\. Cross app-store in-app purchase hosting. At Parse we see a lot of
developers making the same app for Android and iOS. By hosting the content on
Parse, you can use Parse for both your iOS and Android app. Parse would know
how to validate the purchase receipt against iTunes Connect, Google Play,
Amazon AppStore, and other App Stores. Currently Parse does not offer Android
support, but we would be able to do this if there is sufficient demand.

Just some of my thoughts...Hope it helps.

~~~
khangtoh
>> 3\. Hosting content on Parse requires no App Store review, thus introducing
no delay/resubmission via iTunes Connect.

I think that's incorrect unless you are not selling the content through IAP.
You would still need to create an IAP product in order to complete the iTunes
IAP receipt validation.

However, for most games, it's designed so users buy virtual currencies and
content purchases are not directly tie in to IAP products.

~~~
andwang
You are correct in that you would need to create your product and get your
product approved. However, the product's associated content does not need to
be approved. It is my understanding some App store (not necessarily Apple) in
the future may require the content itself be reviewed.

------
kogir
Does Parse validate the SSL certificate in a way that can't be patched at
runtime? If not, it's just as possible to selectively spoof the Parse request
as the Apple request.

Sorry, but untrusted hardware can always win. For a case study of how hard
this is to get right, see Microsoft's Xbox 360 and note that it was still
fully compromised at least once.

