在 Google In-App Billing API 中使用啥作为开发人员有效负载？

Posted 2023-02-19

【中文标题】在 Google In-App Billing API 中使用啥作为开发人员有效负载？

【英文标题】：What to use as the developer payload in Google In-App Billing APIs?在 Google In-App Billing API 中使用什么作为开发人员有效负载？

【发布时间】：2013-02-17 23:42:26

【问题描述】：

training class for Selling In-app Products in android 建议在发出购买请求时使用有效负载：

第五个参数包含一个“开发人员有效负载”字符串，您可以使用它来发送有关订单的补充信息（它可以是一个空字符串）。通常，这用于传递唯一标识此购买请求的字符串令牌。如果您指定字符串值，Google Play 会将此字符串与购买响应一起返回。随后，当您查询此次购买时，Google Play 会返回此字符串以及购买详情。

安全建议：最好传入一个字符串，以帮助您的应用程序识别进行购买的用户，以便您以后可以验证这是该用户的合法购买。对于消耗品，您可以使用随机生成的字符串，但对于非消耗品，您应该使用唯一标识用户的字符串。

Implementing IAB Purchase page 有类似的建议，另外建议应在您自己的安全服务器上检查有效负载值：

安全建议：当您发送购买请求时，创建一个唯一标识此购买请求的字符串令牌，并将此令牌包含在 developerPayload 中。您可以使用随机生成的字符串作为令牌。当您收到来自 Google Play 的购买响应时，请务必检查返回的数据签名、orderId 和 developerPayload 字符串。为了增加安全性，您应该在自己的安全服务器上执行检查。确保确认 orderId 是您之前未处理过的唯一值，并且 developerPayload 字符串与您之前发送的购买请求的令牌相匹配。

查看 Google 用于演示 API 的 Trivial Drive 应用程序的源代码，我发现了以下警告：

* WARNING: Locally generating a random string when starting a purchase and
* verifying it here might seem like a good approach, but this will fail in the
* case where the user purchases an item on one device and then uses your app on
* a different device, because on the other device you will not have access to the
* random string you originally generated.
*
* So a good developer payload has these characteristics:
*
* 1. If two different users purchase an item, the payload is different between them,
*    so that one user's purchase can't be replayed to another user.
*
* 2. The payload must be such that you can verify it even when the app wasn't the
*    one who initiated the purchase flow (so that items purchased by the user on
*    one device work on other devices owned by the user).
*
* Using your own server to store and verify developer payloads across app
* installations is recommended.

所以从所有这些消息来看，使用随机数/字符串作为有效负载听起来是个坏主意。此外，在阅读了最后一个警告之后，将设备 ID 作为有效负载传递听起来也是个坏主意，因为对于不同设备上的同一用户来说，它会有所不同。那么开发者有效载荷应该使用什么？

我的应用提供了用户无需登录任何服务即可访问的本地功能。所以没有“用户”的概念，也没有服务器端组件。应用内购买请求是针对从应用中删除广告的升级。像这样的应用程序使用有效负载功能是否有意义，还是我最好只为它使用一个空字符串并让它容易受到重放攻击？

【问题讨论】：

为什么不让每个人都变得简单，像亚马逊和苹果一样提供外部收据验证服务？

@MichaelWiles 他们这样做了，检查 androidpublisher API (developers.google.com/apis-explorer/#p/androidpublisher/v2)，尤其是 androidpublisher.purchases.products.get 方法

【参考方案1】：

我对 InApp 购买的了解来自较旧的 v2 库。我还没有使用最新的 v3。但是，希望我仍然可以提供帮助。

是的，使用开发人员有效负载作为附加的安全功能肯定会有所帮助，但是您是否应该这样做可能比客观的困境更主观。在我的例子中，我的客户已经有一个服务器，因为客户在购买应用程序后必须下载 200mb 的文件。我们使用开发人员有效负载来存储有关授权下载文件的信息。此信息对于告诉应用如何处理下载的文件至关重要。

我们仍然通过使用服务器调用覆盖本地 verifyPurchase() 方法来提供额外的安全性。 IE，提供我们自己的 nonce 来检查。在本地这样做不是很安全。

至于您的情况，我说这是风险与成本的问题。您的应用程序被黑客入侵和客户绕过购买的风险与实施附加安全性的成本是什么？如果您的应用程序被下载超过 100,000 次，那么您将面临相当大的风险。如果超过 100 万次，则风险很高。如果只有几千，那么盗版可能会忽略你的App。如果您选择增加的安全性，您需要启动并运行服务器，然后添加应用程序和服务器所需的所有代码和握手。所有这些都需要时间和金钱。尤其是在应用程序的生命周期内为服务器付费。

【讨论】：

Android 上的盗版非常普遍。我的应用程序的盗版版本在发布后的几周内就上线了，当时用户还不到 1000 人。仅供参考。