阅读 292

[译] 正确实现 linkedPurchaseToken 以避免重复订阅

你是否在使用 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 没有被设定,移至下一项 等等。

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

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

简单但是重要的事

现在你已经理解 linkedPurchaseToken 字段是怎么工作的,确保在你的后端正确的处理它。每一个有订阅功能的应用都应该检查这个字段。正确的追踪授权对于保证正确的用户,在正确的时间,被授予了正确的权利这一点来说,非常关键。

参考资料

¹重新注册 是指当一个用户订阅,然后取消订阅,接着又在初始的订阅过期之前重新订阅。尽管用户不会丢失授权,新的订阅也和之前的一样,他们还是会经历另一个付款流程,因为他们承诺了未来的付款。他们会收到新的购买令牌并且 linkedPurchaseToken 字段会在升级或者降级的时候被设置。

本文所有的代码都遵循 Apache 2.0 许可。本文不包括 Google 正式产品任何部分,并且只是为了参考使用。

文章开始的令牌图片是从 该链接 复制的。归属:便携式古物计划/大英博物馆基金会。知识共享归属共享 2.0 许可。

感谢 Cartland Cartland

如果发现译文存在错误或其他需要改进的地方,欢迎到 掘金翻译计划 对译文进行修改并 PR,也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。


掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 AndroidiOS前端后端区块链产品设计人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划官方微博知乎专栏

关注下面的标签,发现更多相似文章
评论