使用 Google Checkout Polling API 验证 Android 应用内购买时出现延迟 [英] Delay when verifying Android in-app purchase with Google Checkout Polling API

问题描述

我正在尝试使用 Google Checkout API 从我的服务器验证 Android 应用内购买.根据其他查询(Android 市场上的应用程序 - HTTP 通知不来)，我没有收到回调，所以我正在使用轮询 API.

I'm trying to verify Android in-app purchases from my server using the Google Checkout API. As per this other query (App on Android market - HTTP notifications don't come), I get no callback so I'm using the polling API.

它工作正常，除了我在轮询收到有关购买的通知之前有 5 或 6 分钟的延迟，即使在浏览器中登录到商家帐户的用户已经可以看到所有信息.检查 API 文档，这意味着它可能需要更长的时间，因为它指出使用轮询 API，您可以检索所有不到 180 天且至少 30 分钟前的通知".

It's working fine, except that I'm getting a 5 or 6 minute delay before the polling receives the notifications about a purchase, even though all the information is already visible to the user logged in to the merchant account in a browser. Checking the API documentation, it implies it could take even longer, as it states "Using the Polling API, you can retrieve all notifications that are less than 180 days old and that are at least 30 minutes old".

这种延迟是典型的吗(我在英国)?轮询 API 仍然是验证 Android 应用内购买的推荐方式吗?

Is this delay typical (I'm in the UK)? Is the polling API still the recommended way to verify an Android in-app purchase?

推荐答案

在我看来，尝试通过服务器上的 Google Checkout Polling API 验证 GP LVL 和/或 IAB 信息并不是最好的方法.如果您有服务器，还有更好的选择.

In my opinion, trying to validate GP LVL and/or IAB information via the Google Checkout Polling API on a server is not the best approach. There's a much better option available if you have a server anyway.

如文章保护Android LVL应用程序中所述，最好的方法是在受信任的服务器上验证许可证信息.它是这样的:

As mentioned in the article Securing Android LVL Applications, the best approach is to validate licence information on a trusted server. It goes like this:

1. 不要使用 Google 演示代码；它并不健壮(不检查所有错误情况)，甚至可以被脚本替换，例如伪造响应(虽然，如果您实现如下服务器端检查，那无论如何都无关紧要).直接使用 com.android.vending.licensing.不要将您的 Google Developer Console 应用密钥包含在您的应用中，因为您不需要它.
2. 您的应用程序要求您的服务器为 ILicensingService.checkLicense() 调用提供随机数.您的服务器为您的应用程序提供安全的随机数.您的应用使用该随机数调用 ILicensingService.checkLicense().
3. Android GP LVL Servce 通过 ILicenseResultListener.verifyLicense() 回调您的应用，提供签名数据和签名.(提示:签名数据包含随机数，因此这里甚至不可能进行重放攻击.)
4. 您的应用将签名数据与签名一起传递给您的服务器.
5. 您的服务器是唯一知道您的 Google Developer Console 应用密钥的实例.它根据签名数据验证签名.
6. 验证结果将有助于您做出有关访问服务器数据的身份验证决定.
7. 确保不要过于频繁地检查许可证.谷歌希望你遵守许可证响应提供的有效时间戳(他们声称它甚至反映了 15 分钟的退款期).显然，这只有在您将有效性存储在服务器端并且服务器允许应用跳过步骤 2 中的测试时才是安全的.

1. Don't use the Google demo code; it is not robust (does not check for all error conditions) and can be replaced even by scripts such as to fake a response (although, if you implement the server-side check as below, that's irrelevant anyway). Use com.android.vending.licensing directly. Don't include your Google Developer Console app key with your app, you don't need it there.
2. Your App asks your server for a nonce for the ILicensingService.checkLicense() call. Your server supplies a secure random nonce to your app. Your app calls ILicensingService.checkLicense() with that nonce.
3. The Android GP LVL Servce calls back your app via ILicenseResultListener.verifyLicense(), prodiving signed data and a signature. (Hint: The signed data contains the nonce, so not even a re-play attack is possible here.)
4. Your app passes the signed data along with the signature to your server.
5. Your server is the only instance which knows your Google Developer Console app key. It validates the signature against the signed data.
6. The validation result will contribute to your authentication decision regarding access to server data.
7. Make sure you do not check the licence too often. Google wants you to obey the validity time stamp provided with the licence response (and they claim it even reflects the 15 minute refund period). Obviously, this would only be safe if you store the validity on the server side and the server allows the app to skip the test in step 2.

有一个区别，这同样适用于 IAB.不幸的是，IAB V3 不适用于 getPurchases() 的随机数.原因可能是 IAB 服务本身(而不仅仅是 Google 应用端参考代码)广泛使用缓存.不过，对于购买，您可以将 developerPayload 传递给 com.android.vending.billing.IInAppBillingService.getBuyIntent()，它将包含在 getPurchases() 返回.因此，只要您有无过期条件或某种隐式(基于时间)或服务器管理的显式过期条件-app购买，API还是够安全的；然后服务器会要求应用使用过期的物品，如果失败甚至不是问题，因为服务器仍然知道它并且可以要求应用一次又一次地使用物品.

With one difference, the same applies to IAB. Unfortunately, IAB V3 does not work with a nonce for getPurchases(). The reason is probably that the IAB Service itself (and not just the Google app-side reference code) uses caching extensively. Still, for purchases, you can pass a developerPayload to com.android.vending.billing.IInAppBillingService.getBuyIntent(), which will be included in the signed data which getPurchases() returns. So as long as you have either no expiration criteria or some kind of implicit (time-based) or server-managed explicit expiration criteria for in-app purchases, the API is still safe enough; the server would then ask the app to consume expired items and it's not even a problem if that fails because the server still knows it and can ask the app to consume the items again and again.

我希望我能对这个话题有所了解.

I hope I could shed a bit of light on this topic.

这篇关于使用 Google Checkout Polling API 验证 Android 应用内购买时出现延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！