在我看来,尝试通过服务器上的 Google Checkout Polling API 验证 GP LVL 和/或 IAB 信息并不是最好的方法。如果您仍然有服务器,则有更好的选择。
正如保护 Android LVL 应用程序一文中所述,最好的方法是在受信任的服务器上验证许可证信息。它是这样的:
- 不要使用谷歌演示代码;它并不健壮(不检查所有错误条件),甚至可以被脚本替换,例如伪造响应(尽管,如果您实现如下的服务器端检查,那无论如何都无关紧要)。直接使用
com.android.vending.licensing
。不要在您的应用中包含您的 Google Developer Console 应用密钥,您不需要它。
- 您的应用程序向您的服务器请求一个随机数来
ILicensingService.checkLicense()
调用。您的服务器为您的应用程序提供一个安全的随机随机数。ILicensingService.checkLicense()
您的应用程序使用该随机数调用。
- Android GP LVL Servce 通过 回调您的应用程序
ILicenseResultListener.verifyLicense()
,提供签名数据和签名。(提示:签名数据包含随机数,因此这里甚至不可能进行重放攻击。)
- 您的应用程序将签名数据与签名一起传递到您的服务器。
- 您的服务器是唯一知道您的 Google Developer Console 应用程序密钥的实例。它根据签名数据验证签名。
- 验证结果将有助于您做出有关访问服务器数据的身份验证决策。
- 确保不要过于频繁地检查许可证。Google 希望您遵守许可证响应中提供的有效时间戳(他们声称它甚至反映了 15 分钟的退款期限)。显然,只有将有效性存储在服务器端并且服务器允许应用程序跳过步骤 2 中的测试时,这才是安全的。
有一个区别,这同样适用于 IAB。不幸的是,IAB V3 不适用于getPurchases()
. 原因可能是IAB 服务本身(而不仅仅是 Google 应用端参考代码)广泛使用缓存。不过,对于购买,您可以传递一个developerPayload
to com.android.vending.billing.IInAppBillingService.getBuyIntent()
,它将包含在getPurchases()
返回的签名数据中。因此,只要您没有过期标准或某种隐式(基于时间)或服务器管理的显式应用内购买的过期标准,API 仍然足够安全;然后服务器会要求应用程序使用过期的项目,如果失败,这甚至不是问题,因为服务器仍然知道它并且可以要求应用程序一次又一次地使用这些项目。
我希望我能对这个话题有所了解。