lukaspili / Reactive-Billing

Lightweight reactive wrapper around In App Billing API v3 for Android
https://play.google.com/store/apps/details?id=com.github.lukaspili.reactivebilling.sample
MIT License
247 stars 33 forks source link

Added purchaseData to PurchaseResponse to enable validation of purchases #9

Closed virusman closed 7 years ago

virusman commented 8 years ago

It doesn't validate anything yet, but now gives access to the raw purchase data that can be used to validate the signature.

5

GameDevLlama commented 7 years ago

is this repository still active? Seems like there are several issues and missing features that would really help making this library a great one.

virusman commented 7 years ago

No, looks like it's been abandoned.

GameDevLlama commented 7 years ago

That's sad since currently it seems to be the best rx-solution for billing. I haven't found any other lib for that purpose that is thought through very well.

... well I've forked it and will see if I'll contribute some parts

lukaspili commented 7 years ago

Hi @virusman, @TheWhiteLlama, Sorry for taking so much time to respond.

Why do you need raw purchase data, rather than com.github.lukaspili.reactivebilling.model.Purchase object?

From my understanding, the developer "free to use" field for custom validation is developer payload, which Purchase already exposes. See: https://developer.android.com/google/play/billing/billing_best_practices.html#payload

Did I miss something?

virusman commented 7 years ago

Developer payload is useless for validation unless the entire receipt can be validated with a signature. Here is the relevant info: https://developer.android.com/google/play/billing/billing_integrate.html#billing-security

To help ensure the integrity of the transaction information that is sent to your application, Google Play signs the JSON string that contains the response data for a purchase order. Google Play uses the private key that is associated with your application in the Developer Console to create this signature. The Developer Console generates an RSA key pair for each application.

For client-server apps, validation is essential, and one has to send the raw JSON to the server to be able to validate it.

lukaspili commented 7 years ago

Makes sense, thanks for the explanation and contribution. I will merge and release a new version tomorrow.

virusman commented 7 years ago

I've also made a similar change to getPurchases: https://github.com/virusman/Reactive-Billing/commit/bf1b53506682e95f642fe9ca1633e63a3bc109b6 Do you want me to update this PR?

lukaspili commented 7 years ago

That would be great. What do you think about having an extra field in Purchase named rawJson, rather than having an additional method param String purchaseData?

ycuicui commented 7 years ago

I think you should keep the name purchaseData as this is how Google refers to it. As all fields are final i see no objection to leave it public without getter. The best place is in PurchaseResponse as this is where we found the signature.

lukaspili commented 7 years ago

Merged, thanks!