6

我正在学习如何实现Facebook Fulfillment flow。我无法理解使用request_id（步骤 1 和 2）。这个想法是我的服务器生成request_id，然后当应用程序从 Facebook 获得编码响应时，将该响应中的详细信息与我服务器上存储的详细信息进行比较（request_id用作密钥）。

此验证的目的是什么？

它说：

验证订单的最安全方法是使用 JavaScript 回调中的 signed_request 参数，因为该参数已使用 App Secret 进行编码，客户端无法对其进行操作。

那么，如果我们信任这些数据并且它不能被操纵，为什么我们需要额外的检查呢？另一方面，如果可以对其进行操作，那么此措施如何防止将相同的请求简单地传递到我的服务器并使用返回request_id作为创建操作的一部分signed_request。

4

2 回答 2

1

使用有两个原因request_id

然后可以在支付流程中稍后使用此信息来验证购买不是在客户端和服务器之间进行的，或者在付款 ID 未知的情况下通过调用 Graph API 来检索付款。

  1. 虽然数据不能被操纵，但它确保了额外的安全性。
  2. 可以在不使用付款 ID 的情况下检索付款。

注意：request_id是可选的，您绝对可以使用其他方式达到目的。

  1. 开发者服务器通过解码来自客户端的签名请求并以以下两种方式之一使用支付验证有效负载来验证支付：

    1. 使用 request_id 参数将购买详细信息与步骤 1 中的持久数据进行比较。
    2. 调用 Facebook Graph API 以确认付款详情与预期相符

通过使用signed_request有 2 种方式来验证付款。

  1. 如果您生成 ，request_id则无需对 FB 服务器进行任何进一步的请求即可进行验证，因为request_id在您的数据库中保留了 。因此，使用它的优点之一是request_id可以避免像调用这样的额外请求Graph API。

  2. 如果您没有request_id，那么您必须使用 Payment ID并再次向 FB 提出请求。

请参阅通过 Graph API 验证部分的更多信息。

于 2019-02-19T09:35:32.650 回答
1

让我们分解一下，尝试了解signed_request的使用。

它说， 验证订单的最安全方法是使用 JavaScript 回调中的 signed_request 参数，因为它已使用 App Secret 进行编码，客户端无法操作。

signed_request 由 Facebook 服务器使用只有 Facebook 和应用开发者知道的应用秘密进行编码。如果没有密钥，其他客户端将无法生成 signed_request。因此，这是验证订单的最安全方式。

客户端如何操作signed_request？

如果您的网站易受 XSS 攻击，攻击者可以将 javascript 代码注入您的应用程序。

应用服务器如何知道 signed_request 不是由 Facebook 生成的？

当应用服务器收到signed_request 时，它必须验证singed_request 的签名。只有由 Facebook 生成签名验证才会成功，因为只有 Facebook 拥有您的密钥。

验证数字数据真实性的方法称为数字签名。

于 2019-02-20T19:42:30.550 回答