我有一个Facebook画布应用程序。我正在使用JS SDK在浏览器端对用户进行身份验证，并通过FB.api请求各种信息（例如姓名，朋友等）。
我还希望通过拨打ajax来将一些额外的用户信息（不在Facebook上保存）保存到我服务器上的数据库中：
{ userFavouriteColour: "Red" }
要将其保存在服务器上并与正确的用户关联，我需要知道Facebook的uid，这就出现了问题。如何将uid从客户端传递到服务器。
选项1：将uid添加到ajax请求：
{ uid: "1234567890",
userFavouriteColour: "Red" }
这显然不好。任何人都可以使用其他人的Facebook ID向我的网络服务发出ajax请求并更改他们喜欢的颜色，这是微不足道的。
选项2：在服务器上，从Cookie中提取uid ： 这甚至可能吗？我已经读过Facebook设置了一个包含uid和访问令牌的cookie，但是我是否可以在我的域上访问此cookie？更重要的是，我是否可以安全地从cookie中提取uid，或者就像选项1一样可以进行欺骗。
选项3：服务器上的用户服务器端身份验证： 我可以使用服务器端身份验证来验证服务器上的用户身份。但是如果我已经在浏览器上使用客户端身份验证，这会有效吗？我最终会得到两个不同的访问令牌吗？我想从浏览器发出FB.api请求，所以我需要客户端上的访问令牌（不只是在服务器上）。
这一定是一种非常常见的情况因此我认为我缺少一些基本的东西。我已经阅读了很多Facebook文档（各种身份验证流程，访问令牌，signed_request等）和SO上的很多帖子，但我仍然不明白客户端身份验证和服务器端身份验证如何很好地协同工作。 / p>
简而言之，我想知道用户在服务器上的身份，但仍然从客户端浏览器向Facebook api发出请求？
（我在服务器上使用ASP.NET和Facebook C＃SDK）
编辑：添加了赏金。我希望得到一个关于如何处理这种情况甚至是一个例子的更加敏感的官方建议。如上所述，我已经阅读了许多关于身份验证流程的官方FB文档，但我仍然无法找到关于客户端和服务器端身份验证如何协同工作的明确命令。
答案 0 :(得分：3)
选项1： 我能想到的最简单的方法是在JS中包含accessToken并使用ajax调用传递它。
选项2： 使用与选项1相同的方法，但不是仅发送accessToken，而是发送signedRequest。
在服务器端，您可以使用（TryParseSignedRequest方法）对其进行解码，这将为您提供UserID： - ）
注意：signedRequest使用应用程序Secret进行加密。 你是唯一应该知道它的人，所以你在这方面是安全的。
声明：
我没有C＃的编码经验，但谷歌的一点点搜索给了我这个：
答案 1 :(得分：1)
实际上非常简单。
当用户加载app时，使用server side authentication，获取访问令牌并通过从服务器发出api请求来加载用户数据。
在服务器端，您将拥有所需的一切，并且它是沙箱。
当页面呈现给用户时，使用js sdk获取用户身份验证数据，您应该可以使用FB.getLoginStatus，因为用户已经通过了服务器端身份验证。
现在在客户端，您还有一个访问令牌，您可以使用该令牌从图api中获取用户数据。
两个令牌会有所不同，并且也会有不同的过期，但这不应该是一个问题，两个令牌都应该正常工作，如你所期望的那样。
由于双方都有自己的令牌和向api发出请求的方式，因此无需在它们之间发送任何fb数据。
所以你提到的第三个选项对我来说听起来最好，而且实现起来也很简单。
所有facebook SDK都只是http请求的包装器，因为整个fb api是在http请求上发出的 SDK只是让您轻松，简单地访问数据，而无需自己构建URL（包含所有不同的可能参数），发出请求并解析响应。
说实话，我认为停止为C＃SDK提供支持服务器端身份验证的方法是一个非常糟糕的决定。
提供不实现整个api的SDK有什么意义？
根据我的经验，您的问题的最佳答案是使用服务器端和客户端身份验证，并且由于C＃SDK不支持它，我建议您创建自己的SDK。 它并不复杂，我已经为python和java（两次）实现了它，并且因为你将根据自己的需要开发它，它可以根据你的确切需求进行定制，不像公共SDK应该支持所有可能的选项。
无需创建全新的SDK，您只需“扩展”您正在使用的SDK并添加所需的缺失部分，例如服务器端身份验证支持。
答案 2 :(得分：0)
我不知道它是否是特定于语言的，但使用服务器端和客户端身份验证都没有坏处。
您可以使用选项2，但是，这也很容易受到欺骗。
执行选项3，您将拥有该用户会话的单一访问令牌，因此根据我的最佳选择，因为您在从客户端传递用户信息时总是有欺骗的可能性。
答案 3 :(得分：0)
我最近有同样的问题。这是选项2.从Facebook博客中查看this post。
老实说，我不足以知道你是否可以欺骗cookie中的UID，但这似乎是“官方”的方式。
编辑：对于选项2下的其他问题，是的，我相信您必须在您的域名中访问此Cookie。