Reinstate IInAppBillingVerifyPurchase parameter to GetPurchasesAsync()

[philtomblin]

Changes Proposed in this pull request:
Reinstates the IInAppBillingVerifyPurchase parameter to GetPurchasesAsync() (was in v2 nuget but removed in v4). This allows purchases (especially subscriptions) to be restored securely, even if historic backend records are unavailable. The default value is null (as per previous implementation), making this a non-breaking change. The new implementations for Apple and Android are similar to the original implementation, but adapted for the v4 changes.

@jamesmontemagno Many thanks for the awesome library and apologies if I have missed anything or broken protocol in some way - this is my first PR to someone else's project! 🙏

[jamesmontemagno]

Couldn't you just call this yourself outside of the method? Not sure why it has to be doing 2 things in side of there. That is why I removed it, you could just verify the purchases yourself with the information provided.

[philtomblin]

Calling outside, I have to pass the "purchase token" as that is what is returned in the InAppBillingPurchase. However, for iOS auto-renewing subscriptions (I've only just started work on Android IAP so maybe there is no issue that side), when sending this to my backend, which in turn sends to Apples auth service, I get invalid JSON back (from Apple). I suspect this is because the "purchase token" is not the same thing as the Apple receipt (obtained from NSBundle.MainBundle.AppStoreReceiptUrl) and Apple's endpoint is returning invalid output because the input is invalid. When I send the receipt (using your code linked below), it all works perfectly, just as it did on v2.

InAppBillingPlugin/src/Plugin.InAppBilling/InAppBilling.apple.cs

Line 217 in af4f096

Task<bool> ValidateReceipt(IInAppBillingVerifyPurchase verifyPurchase, string productId, string transactionId)

There a few possible solutions here:

1. Create a custom JSON parser to parse the invalid response I'm getting from Apple - I don't think this is sensible
2. Amend InAppBilling.apple.cs to return the receipt - avoids "doing 2 things" in GetPurchasesAsync() but may have other side-effects...?
3. Copy-paste the ValidateReceipt method (linked above) into my app's iOS project - this is doable and certainly works, but doesn't seem right, as the library surely ought to handle this (other people will hit the same issue and it won't be obvious how to resolve)
4. Reinstate the IInAppBillingVerifyPurchase parameter to GetPurchasesAsync()

Logically, securely verifying restored purchases is no different to securely verifying a new purchase (and uses exactly the same code) - hence the approach I took to reinstate what you did originally.

[jamesmontemagno]

So in my 5.0 beta i am going to add the "OriginalJson" and "Signature" to the purchase that comes back from android. That should be enough for you to call it on android. Then on iOS I am goign to make "VerifyPurchase" public static so you can just call it from your app.

[philtomblin]

If you're exposing the raw info for Android in 5.0 then the ideal for iOS would be to return the receipt in the purchase. That way, an app dev can just call their backend using that value, without the need for IInAppBillingVerifyPurchase anywhere.

So are you okay with this PR for v4, or is v5 fairly imminent? Happy to help with beta testing for v5 when it's ready, BTW.

[jamesmontemagno]

@philtomblin so you should be good to go now with version 5.0.1-beta

I have added
OriginalJson and Signature to the InAppBillingPurchase.

Then I also added a property to access the receipt url data -> CrossInAppBilling.Current.ReceiptData

I have removed IInAppBillingVerifyPurchase from all of the methods now so the dev can filter them now on their side.

Will close this as it will be replaced with #399

Appreciate you working with me on this :)

[philtomblin]

@jamesmontemagno Many thanks for this - I will work to update my app accordingly at the weekend!

[jamesmontemagno]

let me know how it goes