为什么使用应用内结算设置开发人员有效负载很重要？

我正在使用应用内结算API的版本3。我有一个受管理的非消耗性物品。我尚未在我的应用程序中发布此功能，因此我想在购买之前确定购买的有效载荷内容。

来自“安全最佳实践”：

发出购买请求时设置开发人员有效负载字符串

使用应用内结算第3版API，在将购买请求发送到Google Play时，您可以包括“开发人员有效载荷”字符串令牌。通常，这用于传递唯一标识此购买请求的字符串令牌。如果您指定字符串值，则Google Play会返回此字符串以及购买响应。随后，当您对此次购买进行查询时，Google Play会返回此字符串以及购买详细信息。

您应该传递一个字符串令牌，该令牌可以帮助您的应用程序识别进行购买的用户，以便以后可以验证该用户是否进行了合法购买。对于消耗品，您可以使用随机生成的字符串，但是对于非消耗品，则应该使用唯一标识用户的字符串。

当您从Google Play取回响应时，请确保验证开发人员有效负载字符串与您先前与购买请求一起发送的令牌匹配。作为进一步的安全预防措施，您应该在自己的安全服务器上执行验证。

对与错，我决定不采取设置服务器以进行购买验证的“进一步的安全预防措施”。而且我不会存储自己的购买记录-我总是调用计费API。那么，我真的有理由进行此有效负载验证吗？验证API本身在举报购买商品之前肯定会验证用户的身份，并且如果攻击者破坏了设备（应用程序或Google Play API），我看不出对其进行额外检查会没有任何好处用户在设备上可以轻易绕过的身份。还是有我没有想到的这样做的理由？

如果您不保留记录，则无法验证您所收到的是您发送的。因此，如果您将某些内容添加到开发人员有效负载中，则可以信任它是合法的（如果签名经过验证，这是一个合理的假设），也可以不完全信任它，而仅将其用作引用，而不用于验证许可证状态，等等。例如，如果存储用户电子邮件，则可以使用该值而不是要求他们再次输入它，这对用户更友好，但是如果应用程序不存在，则应用程序不会中断。

就我个人而言，我认为整个“最佳实践”部分令人困惑，并试图使您完成API真正应该做的工作。由于购买是与Google帐户绑定的，并且Play商店显然会保存此信息，因此他们应该在购买详细信息中提供此信息。获取正确的用户ID需要其他权限，您无需添加其他权限即可弥补IAB API的不足。

因此，简而言之，除非您拥有自己的服务器和特殊的附加逻辑，否则请不要使用开发人员有效负载。只要IAB v3 API可以工作就可以了（不幸的是，这时很大的'if'）。

您应该传递一个字符串令牌，以帮助您的应用程序识别进行购买的用户...

如果您的应用程序提供了自己的用户登录名和身份（与手机所连接的Google帐户不同），则您需要使用开发者有效负载将购买的商品附加到进行购买的其中一个帐户中。否则，有人可以在您的应用程序中切换帐户，并从购买的东西中受益。

例如

假设我们的应用程序已经登录了userA和userB。手机的Android google帐户是X。

1. userA，登录我们的应用并购买终身会员。购买详细信息存储在Google帐户X下。
2. userA注销，而userB登录到我们的应用程序。现在，由于Android google帐户仍为X，因此userB还可以享受终身会员资格。

为避免这种滥用，我们会将购买绑定到一个帐户。在上面的示例中，我们将在userA进行购买时将开发人员有效载荷设置为“ userA”。因此，当userB登录时，有效负载将与登录的用户（userB）不匹配，我们将忽略购买。因此，用户B无法获得用户A进行购买的好处。

开发人员有效载荷处理还有另一种方法。正如Nikolay Elenkov所说的那样，需要用户ID并为您的应用程序的用户配置文件设置其他权限的开销太大，因此这不是一个好方法。因此，让我们看看Google在In-App Billing v3示例中最新版本的TrivialDrive示例应用中所说的内容：

• 警告：开始购买时在本地生成随机字符串并在此处进行验证似乎是一种好方法，但是如果用户在一个设备上购买商品然后在其他设备上使用您的应用程序，则此操作将失败。另一台设备将无法访问您最初生成的随机字符串。

因此，如果您要在另一台设备上验证购买的商品，则随机字符串不是一个好主意，但是他们仍然说这不是验证购买响应的好主意。我会说-使用开发人员有效负载仅用于通过发送随机唯一字符串来验证购买，将其保存在首选项/数据库中，并在购买响应中检查此开发人员有效负载。至于在“活动开始”时查询广告资源（应用内购买）的原因-不要麻烦检查开发人员的有效负载，因为这可能会在没有存储该随机唯一字符串的另一台设备上发生。我就是这样看的。

这取决于您如何验证developerPayload。有两种方案：远程验证（使用服务器）和本地验证（在设备上）。

服务器

如果您使用服务器进行developerPayload验证，那么它可以是任意字符串，可以在设备和服务器上轻松计算。您应该能够识别执行请求的用户。假设每个用户都有对应的accountId，则developerPayload可以将其计算为与purchaseId（SKU名称）的组合，例如：

MD5(purchaseId + accountId)

设备

developerPayload 不应是用户电子邮件。为什么不应该使用电子邮件作为有效负载的一个很好的例子是Google for Work服务。用户可以更改其与该帐户关联的电子邮件。唯一不变的是accountId。在大多数情况下，电子邮件可以接受（例如，目前Gmail地址是不可变的），但请记住要为将来设计。

多个用户可能使用同一台设备，因此您必须能够区分谁是商品的所有者。对于设备验证，developerPayload是一个唯一标识用户的字符串，例如：

MD5(purchaseId + accountId)

结论

通常developerPayload，两种情况下的都可能只是accountId。对我来说，这似乎是默默无闻的安全感。MD5（或其他哈希算法）purchaseId只是使有效负载更加随机的一种方式，而无需明确表明我们使用的是帐户ID。攻击者必须反编译应用程序才能检查其计算方式。如果您对应用程序感到困惑，那就更好了。

有效负载不提供任何安全性。可以很容易地用“设备”方法欺骗它，而无需花费任何精力在“服务器”检查中。请记住使用Google Publisher帐户控制台中提供的公共密钥来实施签名检查。

*有关使用帐户ID（而非电子邮件）的必读博客文章。

在琐碎的驱动器示例作者自己提供的有关IAB v3的Google IO视频中，在视频结尾处对此进行了简要介绍。这是为了防止重放攻击，例如，攻击者嗅探流量，窃取包含成功购买的数据包，然后尝试在自己的设备上重放数据包。如果您的应用在发布高级内容（理想情况下也来自服务器）之前没有通过dev有效负载（最好在服务器上）检查购买者的身份，攻击者将成功。由于数据包完好无损，因此签名验证无法检测到。

在我看来，这种保护似乎对于具有在线帐户连接性（例如部落冲突）的应用程序是非常理想的（有效载荷是自然产生的，因为无论如何您都必须识别用户），尤其是在黑客行为破坏多人游戏玩法的同时，除了简单的本地化盗版案例以外，其影响深远。相反，如果apk上的客户端黑客已经可以解锁高级内容，则此保护不是很有用。

（如果攻击者试图欺骗有效载荷，则签名验证应该会失败）。

2018年末更新：官方Google Play计费库有意不公开developerPayload。从这里：

字段developerPayload是一个旧字段，保持与旧实现的兼容性，但正如“购买应用内结算产品”页面（https://developer.android.com/training/in-app-billing/purchase-iab -products.html），在完成与应用内结算相关的任务时，此字段并非始终可用。并且由于该库旨在代表最新的开发模型，因此我们决定在实现中不支持developerPayload，并且我们也没有计划将该字段包含在库中。

如果您将任何重要的应用内结算逻辑实现依赖于developerPayload，我们建议您更改此方法，因为此字段在某个时候（或很快）将被弃用。推荐的方法是使用自己的后端来验证和跟踪有关订单的重要详细信息。有关更多详细信息，请查看“安全和设计”页面（https://developer.android.com/google/play/billing/billing_best_practices.html）。

我为此苦苦挣扎。由于Google Play帐户只能拥有任何“托管”项目中的一个，但是可以拥有多个设备（我拥有三个设备），因此，某人出售“每台设备”的上述评论将不起作用...能够将其放到他们的第一台设备上，再也没有其他任何设备上……如果您购买高级升级，则它应该可以在所有手机/平板电脑上使用。

我鄙视获取用户电子邮件地址的概念，但是我真的没有找到其他可靠的方法。因此，我在帐户列表中抓取了一个与“ google.com”匹配的第一个帐户（是，添加到清单的权限），然后立即对其进行哈希处理，因此它不再可用作电子邮件地址，但确实提供了“足够唯一”令牌。这就是我作为开发人员有效负载发送的内容。由于大多数人都使用其Google Play ID激活其设备，因此很不错，这三台设备都将获得相同的令牌（在每台设备上使用相同的哈希算法）。

它甚至可以在具有多个“用户”的KitKat上使用。（我的开发人员ID在一个用户上，我的测试ID在另一个用户上，每个用户都在自己的沙箱中）。

我已经在总共3个用户的六台设备上对它进行了测试，并且每个用户设备都返回了相同的哈希值，并且不同的用户都具有不同的哈希值，满足了准则。

我从来没有存储用户的电子邮件地址，它是直接从代码中传递的，以将帐户名传递给哈希函数，并且仅哈希存储在堆中。

可能还有更好的解决方案，可以更加尊重用户的隐私，但是到目前为止，我还没有找到它。应用发布后，我将在隐私权政策中对如何使用用户的电子邮件地址进行非常清晰的描述。

这通常会响应产品定义（您的应用程序）。例如对于订阅的情况。同一用户将能够在他/她拥有的所有设备上使用订阅吗？如果答案是肯定的。我们没有检查有效载荷。

用于消耗品。假设您在应用程序中购买了10个虚拟硬币。用户能否在不同设备上使用这些硬币？一台设备上为4，另一台设备上为6？如果我们只想在进行购买的设备上工作，则必须检查有效负载，例如使用自生成的字符串并本地存储。

基于这些问题，我们必须决定如何实施有效负载检查。

问候

圣地亚哥