[译] 正确实现 linkedPurchaseToken 以避免重复订阅-CSDN博客

原文地址：Implementing linkedPurchaseToken correctly to prevent duplicate subscriptions
原文作者：Emilie Roberts
译文出自：掘金翻译计划
本文永久链接：github.com/xitu/gold-m…
译者：yuwhuawang
校对者：zx-Zhu

你是否在使用 Google Play 的订阅功能？要确保你的后端服务实现的方式是正确的。

订阅 REST APIs 是管理用户订阅的真实可信来源。Purchases.subscriptions API 的返回包括一个非常重要的字段叫做 linkedPurchaseToken。 恰当的处理这个字段，对于保证正确的用户能够访问你的内容是非常重要的。

它是如何工作的？

就像订阅文档里指出的, 每一笔新的 Google Play 的购买流程 —— 初始化购买、升级和降级还有重新注册¹ —— 都会产生一个新的购买令牌。而 linkedPurchaseToken 字段则可以用来识别属于同一个订阅的多个购买令牌。

打个比方，一个用户购买了一个订阅并且收到一个购买令牌 A。linkedPurchaseToken 字段（灰色圆圈）在 API 的返回里没有值，因为这个购买令牌属于一个全新的订阅。

如果用户升级了他们的订阅，一个新的购买令牌 B 产生了。既然这个升级替代了购买令牌 A 代表的订阅，令牌 B 的 linkedPurchaseToken 字段（灰色圆圈显示的）将会指向令牌 A。注意它按照时间的逆序指向原始的购买令牌。

购买令牌 B 将会是唯一被更新的令牌。购买令牌 A 不应该用来授权用户获取你的内容。

注意： 更新订阅时，如果你查询 Google Play 的订单服务器，购买令牌 A 和 B 都会是激活的。我们会在下一节里讨论这个问题。

现在，让我们假设一个另一个用户执行了以下操作：订阅、升级和降级。原始的订阅会创建购买令牌 C，升级操作会创建购买令牌 D，降级操作会创建购买令牌 E。每一个令牌都会按照时间的逆序指向前一个令牌。

让我们在这个例子里加上第三个用户。这个用户一直在改变主意。在初始化订阅之后，用户又一连三次取消了订阅然后重新订阅（重新订阅）。初始化订阅创建了购买令牌 F，重新订阅创建了 G、H 和 I。购买令牌 I 是最近的令牌。

最近的令牌 B、E 和 I 分别代表了用户 1、2、3 的最终授权和付账的订阅。只有这些最近的令牌才有相应的权利。然而对于 Google Play 来讲，如果初始的过期时间还没到，所有的令牌都是“有效的”。

也就是说，如果你通过获取订阅 API 来查询这些令牌，包括上面的图表内的 A, D, F, G和H，你会得到订阅资源响应，响应里表明订阅还没有过期并且付款已经收到，即便如此你也只应该根据最近的令牌来授权。

第一眼看上去很奇怪：为什么最初的令牌还是在被更新后还是有效的？简单来说是这样实现能让开发者更灵活地提供内容和服务，也让 Google 更好的保护用户隐私。然而这也确实需要你在后端服务器上进行重点记录

操作 linkedPurchaseToken

每次当你确认一个订阅，你的后台服务都应该检查 linkedPurchaseToken 字段有没有被设定。如果已经被设定，该字段的值就代表着前一个被替换的令牌。你应该立刻把前一个令牌标记为失效，这样用户就不能使用这个令牌访问你的内容。

我们再来看看上面例子里的用户 1, 当后端服务器收到了代表初始购买的凭证 A，该凭证 A 的 linkedPurchaseToken 字段为空，这时应根据凭证进行授权。接下来，当后端服务器接收到更新后新的购买凭证 B，服务器会检查 linkedPurchaseToken 字段，发现它被设置为令牌 A，于是就禁掉令牌 A 的授权。

这样的话，后端数据库总是保存有效权限的购买凭证。以用户 3 的例子来说，数据库的状态变化应该如下图：

检查 linkedPurchaseToken 的伪代码：

你可以在一个开源的，端对端订阅的应用优雅出租车的后台 Firebase 上看一些例子，特别是看 disableReplacedSubscription 方法，它在 PurchasesManager.ts 里。

清理现有的数据库

现在你的后端应该和最新的，接连到来的购买令牌保持同步，你会检查每一个购买的 linkedPurchaseToken 字段，并且每一个对应着被替换订阅的令牌，都被正确的禁用了。这太棒了！

但是如果你有一个已有的订阅数据的数据库，并且没有根据 linkedPurchaseToken 字段来调整？你需要在这个数据库上跑一个一次性的清理算法。

在很多情况下清理数据库中最重要的工作就是，一个令牌是否被能够授权相应的内容和服务。也就是说：并不需要对每一个订阅重新创建升级/降级/重新订阅的购买历史，而只需要确定每个令牌正确的授权情况。一次性的数据库清理任务就可以把订阅状态整理清楚。接下来，新到来的订阅就需要像上一节中描述的那样处理。

想象一下上面三个用户的购买凭证都存在数据库里。这些购买可能出现在任何时间，顺序也不一样。如果清理功能正确处理的话，令牌 B、E 和 I 最终会被标记为有效授权，而其他的令牌则会被禁用。

对数据库进行一次遍历，并检查每一项。如果 linkedPurchaseToken 字段被设置，就把这个字段包括的字段禁用。根据下面的图表，我们从上到下移动：

元素 A：linkedPurchaseToken 没有被设定，移至下一项元素 D：linkedPurchaseToken == C，禁用 C 元素 G：linkedPurchaseToken == F，禁用 F 元素 E：linkedPurchaseToken == D，禁用 D 元素 F：linkedPurchaseToken 没有被设定，移至下一项等等。

清理现有数据库的伪代码：

执行完一次性的清理之后，所有的旧令牌都会被禁用，你的数据库也就准备好了。