验证应用内购买

Question

我正在构建一个提供应用内购买的 Windows 应用商店应用。从可用的文档中我不明白这如何与多个安装或设备一起工作。我希望我的用户能够在不同设备上使用多个安装的 IAP（购买一次，在任何设备上使用）。

这是Using receipts to verify purchases的摘录：

在某些情况下，您可能需要验证用户是否购买了您的 应用程序，或已进行应用内内容购买。例如，想象一个游戏 提供下载的内容。如果购买游戏的用户 内容想要在不同的 Windows 8 设备上播放，您需要 验证用户是否已经拥有该内容。

还有来自Protecting your Windows Store app from unauthorized use：

为防止用户采用此策略非法使用您的 应用程序，我们有一个收据功能，可让您验证用户的 访问您的应用程序和服务。您的应用程序能够获得签名 通过 Windows 进行的任何与应用程序相关的交易的收据 商店，例如应用程序的初始购买和任何应用程序内 购买。然后，您的应用可以使用此信息来确定哪些服务 或它可以为该用户访问的功能。 [...] 每张收据的 ID 每个用户（和设备）元素都是唯一的，您可以在 您的服务器确认交易是合法的 用户而不是欺诈交易。这是特别有价值的 当您的应用拥有自己的身份验证机制时，因为它允许 您验证似乎已购买您的应用程序的每个用户 是，事实上，一个独特的客户。

我的问题是：

1. 什么时候需要后端来存储收据？
2. 我什么时候在后端检查收据（应用启动时）？
3. 每台设备的收据都是唯一的。这对多个设备有何帮助？我希望我的用户能够在购买一次后在多台设备上使用 IAP。
4. 如果收据用于验证合法交易，这是否意味着CurrentApp 组件提供的信息可能不是真实的，而是经过黑客攻击？如果是这样，我为什么要首先信任原始收据？

Answer 1

1. 可以在设备上检查 XML 签名没有任何问题，但设备可能会受到损害（理论上），最好在您的服务器上检查它（我认为这个例子是关于一些可以购买或在线购买的游戏具有可下载内容的杂志应用程序）。
2. 当用户尝试使用它或获取可用的东西时。在开始时，如果它对应用程序工作很重要。没有限制，但这需要一些时间，用户应该知道应用正在做某事，而不仅仅是挂起。
3. ID 看起来像是一个值，您应该存储在后端（在用户帐户中）并根据每个 DeviceId 对其进行验证。然而，还有 ProductId 和签名足以检查一致性。
4. 当然可以妥协。黑客可以替换证书检查 URL，您将通过检查。这就是为什么他们建议使用后端并在您自己的服务器上检查证书的原因（但是，理论上，您的服务器也可能受到损害；）

检查收据的最佳方法：

1. 在应用中获取收据。
2. 将收据发送到后端。
3. 在后端检查收据并允许用户下载付费内容（如果收据无效）。