Differentiate unavailability from failed validation

[benji101]

First, thanks for this library, it's a lot of good work!

Maybe I'm missing something (I'm new to Node.js), but I'm trying to split between 3 cases that can happen when trying to validate a Google Play subscription:

• Subscription is valid
• Subscription is not valid (subscription canceled, expired or possibly someone hacking)
• Subscription could not be verified (Google down or other error)

Regarding this, I have two questions:

• does .isValidated() only return true if the subscription is valid (meaning the subscription is active and the purchaseToken was valid)?
• I seem to fall in the "error catch" both if Google API is not available or if the purchase token doesn't exist. How to differentiate the two cases if I don't want the same behavior?

Here is the snippet I'm using, and I'd like to know how to tweak it to get the behavior I want.

iap.setup()
    .then(() => {
        iap.validate(receipt)
          .then( function (response) {
              if (iap.isValidated(response)) {
              // subscription is valid
              } else {
              // Subscription is not valid (subscription canceled or expired)?
           }
      })
      .catch( function (error) {
      // failed to validate the receipt...
     // Google unavailable or hack? 
     });
})
.catch((error) => {
  // error...
  // Google unavailable or hack? 
});

Thanks again for the great work!

[voltrue2]

Hello,

isValidated() is a function that I added when there was no subscription purchase available. It still gives you wheather your receipt is valid or not but cannot give you details.

The best approach to catch all cases is what you are doing at the moment.

It is a little messy as there are three possible routes...

Anyways, if you have suggestions, I am always open to new ideas.

Cheers

On Jan 11, 2019 at 05:57, <benji101 (mailto:[email protected])> wrote:

First, thanks for this library, it's a lot of good work!

Maybe I'm missing something (I'm new to Node.js), but I'm trying to split between 3 cases that can happen when trying to validate a Google Play subscription:

Subscription is valid

Subscription is not valid (subscription canceled, expired or possibly someone hacking)

Subscription could not be verified (Google down or other error)

Regarding this, I have two questions:

does .isValidated() only return true if the subscription is valid (meaning the subscription is active and the purchaseToken was valid)?

I seem to fall in the "error catch" both if Google API is not available or if the purchase token doesn't exist. How to differentiate the two cases if I don't want the same behavior?

Here is the snippet I'm using, and I'd like to know how to tweak it to get the behavior I want.

iap.setup() .then(() => { iap.validate(receipt) .then( function (response) { if (iap.isValidated(response)) { // subscription is valid } else { // Subscription is not valid (subscription canceled or expired)? } }) .catch( function (error) { // failed to validate the receipt... // Google unavailable or hack? }); }) .catch((error) => { // error... // Google unavailable or hack? });

Thanks again for the great work!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (https://github.com/voltrue2/in-app-purchase/issues/236), or mute the thread (https://github.com/notifications/unsubscribe-auth/ACKY4cn-b7e0vBfamceUpjTzFCg_7YoJks5vB6lNgaJpZM4Z6TXs).

[benji101]

Ok, but my main question is still: How to differentiate a server error (for example, a 503 error) from an error because the purchase token doesn't exist (404 error from google). If I understand correctly, both error will cause the function .validate() to throw, so how can I differentiate them in the catch block? Is there a simple way to get the response code from the catch block?

[voltrue2]

Hello,

I missed the question there. Sorry about that. At the moment, you cannot really tell them apart from expected error to HTTP error such as 503 etc...

[sardon]

+1 !!

I agree that this is a desirable feature - it would allow to distinguish a system failure from a hacking attempt.

If a system failure, you may want to grant entitlements (depending on your use case), if hacking attempt you don't want to grant entitlements.