了解Facebook付款的实现流程

Question

我正在学习如何实现Facebook Fulfillment flow。 我无法使用request_id（步骤1和2）。这个想法是我的服务器会生成request_id，然后在应用收到来自Facebook的编码响应后，将响应中的详细信息与服务器上存储的详细信息进行比较（使用request_id作为键）。

此验证的目的是什么？

它说：

  

验证订单最安全的方法是使用signed_request   JavaScript回调中的参数，因为该参数已使用   应用秘密，并且不能由客户端操纵。

因此，如果我们信任此数据并且无法对其进行操作，为什么还要进行附加检查？另一方面，如果可以对其进行操作，则此措施如何防止将同一请求简单地传递到我的服务器，并将返回的request_id用作创建受控signed_request的一部分。

Answer 1

使用request_id

的有两个原因

  

此信息随后可以在付款流程中用于验证   没有在客户端和服务器之间操纵购买行为，   或在实例中通过调用Graph API检索付款   付款ID未知的地方。

1. 尽管无法操纵数据，但可以确保额外的安全性。
2. 无需使用付款ID即可检索付款。

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

  

  

1. Developer Server通过解码来自客户端的签名请求并使用以下两种方式之一使用付款验证有效载荷来验证付款：

        
     
   1. 使用request_id参数比较购买明细   针对来自步骤1的持久数据。
     
   2. 调用Facebook Graph API以确认付款细节是否符合预期
     
  

使用signed_request可以通过两种方式验证付款。

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

2. 如果您没有request_id，则必须使用Payment ID并再次请求FB。

See more on the Verification via Graph API section.

Answer 2

让我们对其进行分解，并尝试了解对signed_request的使用。

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

  

signed_request由Facebook服务器使用应用程序密码编码   只有Facebook和App Developer知道。没有其他客户会   能够在没有密钥的情况下生成signed_request。因此，这是   验证订单最安全的方式。

客户端如何处理signed_request？

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

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

应用服务器接收到signed_request时，必须验证singed_request的签名。签名验证只有在Facebook生成的情况下才能成功，因为只有Facebook拥有您的密钥。

验证数字数据真实性的方法称为Digital Signature。