【问题标题】:Why confirm purchase using postback URL?为什么使用回发 URL 确认购买?
【发布时间】:2013-07-17 09:04:30
【问题描述】:

Google Wallet docs(针对数字商品)说:

注意:这些回调处理程序并不安全。有人可以使用 Firebug 或 Chrome 开发者工具调用其中一个函数, 嘲笑成功或失败。 您应该确认购买on the server

引用中的链接用于指定回发 URL。

但既然 jwt 是由 Google 签名的 - 为什么需要这样做?我们可以在服务器上的页面代码隐藏中简单地检查 成功处理程序 的 jwt 的签名。

(如果签名还不够——回发网址也不应该足够,因为如果有人发现了这个网址——他们可能会在那里发送一个 POST 并且问题会再次出现。)

【问题讨论】:

    标签: android-pay


    【解决方案1】:
    1. 回调 url 的目的是让您知道已经进行了购买
    2. 您在实际“使用”数据之前验证发布的数据,您的回发网址是否在野外“被发现”无关紧要。
    3. 您告诉 Google,您能够成功在您的系统中记录上述订单,并且您可以“履行”上述订单。否则,如果由于任何原因您的终端无法记录/处理/等订单,这意味着您不会“履行”,那么用户(买家)也必须知道。

    我没有测试过这个(我使用回发网址)

    文档声明 *IF* you specify a postback url 。因此,您可以尝试不提供并按照上面描述的方式进行处理(仍然是“服务器端”)。

    可能的问题

    假设你的测试有效,两者的区别:

    • 带有回发网址的场景中,所有相关方、买家、您和 Google 都“同步” - 如果您因任何原因无法履行,则存在一些服务器问题等,则所有的交易失败(未生成订单)。

    • 没有回发url的场景中,假设成功,事务可能有不同的状态:

      • Google:良好,记录在买家的电子钱包交易列表中
      • 您的系统:可能好,也可能不好,甚至没有记录
        • 根据您的页面处理数据的方式当时
        • 客户端/浏览器上的任何脚本错误,或来自客户端的任何其他可能阻止您的页面处理的原因
      • 用户/买家 - 在他/她的电子钱包交易中有订单 - 就 Google 而言“成功”

    希望这会有所帮助...

    更新:

    在安全方面还有另一个“好处”(在某些流程中可能很关键)。使用回发 url,您可以获得另一个验证步骤的订单详细信息(例如,基于 order-id)。您可以验证客户端发送/发送的订单是否“有效”(无论业务规则如何 - 例如if order-id exists then.....),因为成功回调发生在回发之后

    例如通过重播相同(有效)JWT(在 iat/任何过期范围内)进行模拟

    卖家/开发者可能会在他们的应用中提出无数的流程,因此使用“回发网址验证流程”可以缓解可能出现的问题。

    第……

    【讨论】:

    • a) 谢谢。 b)我并不是要质疑回发网址的好处(尽管我现在看到我的问题是这样措辞的)。我正在质疑暗示它必须用于避免虚假成功的引用。
    • 我对您的回答的理解是,如果在代码隐藏中检查了成功处理程序的 jwt 签名 - 它确实是安全的(不过,由于其他原因,这可能是错误的处理方式,因为您已经指出。)我希望我理解正确。
    【解决方案2】:

    我使用回传来交付货物(在我们的例子中是电子客票)。我已经实现了钱包回发,这给了我各种参数,比如谷歌的 user_id。

    我不知道如何确定用户是谁,没有这个,我无法向他们发送数字商品。有什么办法可以得到这个吗?

    在其他系统上,我曾经提供进入支付按钮并通过回调出来的订单 ID。我在钱包代码示例或教程中没有看到这样的输入。

    谢谢保罗

    注意:我后来猜到了答案,测试了一下,在这里提供:how to get user information in google wallet

    【讨论】:

      【解决方案3】:

      就像文档说的那样,所有客户端代码都可以使用各种浏览器开发工具轻松更改,因此不应该被信任。

      我认为他们担心的是 javascript 可能会被操纵,以便您的服务器认为已经付款,而用户获得了他们实际上并未支付的产品。

      如果有人发现了这个 URL 并在上面发帖,他们就无法控制服务器代码,所以服务器会从他们的卡中收取费用,所以这不是问题。

      【讨论】:

      • 谢谢。但是我的服务器会检查成功处理程序的 jwt 签名。而且由于操作 JavaScript 不会在服务器上操作页面的代码隐藏 - 这不是问题。
      • @ispiro 如果您的服务器正在检查 jwt 的签名,那么您所做的正是 google 告诉您的。如果您从客户端执行此操作(即,让 javascript 使用 jwt 数据调用您的服务器),jwt 的来源是未知的,并且可能被 javascript 注入脚本模拟...如果您从回发 URL 执行此操作,您确定它来自 Google(并且您也向 Google 承认了这一点)。
      • @Jcl then you are doing EXACTLY what google tells you to do - 不。这就是我写的原因(尽管是小文本):The link in the quote being to specifying a postback URL.
      • 是的,这就是我后来解释的...如果您服务器上的 JWT 来自客户端脚本,则可以模拟...如果它来自 Google 的回发 URL ,它不能(或者......不是那么容易)
      • @jcl - 签名不能被模拟。这正是签名的重点。 (请参阅我在问题中的最后评论。)
      猜你喜欢
      • 1970-01-01
      • 2022-09-28
      • 2022-01-05
      • 2022-12-24
      • 1970-01-01
      • 2022-01-18
      • 2015-06-28
      • 2021-07-01
      • 2019-10-28
      相关资源
      最近更新 更多