Edit

Question

我使用JSSDK验证浏览器的用户, 通过FB.api(例如姓名、朋友等)索取各种信息。

我还想通过拨打ajax电话, 维持我服务器上数据库的更多用户信息(不在Facebook上) :

{ userFavouriteColour: "Red" }

为了在服务器上保存这个信息, 并与正确的用户连接, 我需要知道 Facebook 的 uid, 这带来了一个问题。我如何将 uid 从客户端传送到服务器。

<强度 > 备选1:在 ajax 请求中添加代号 :

{ uid: "1234567890",
  userFavouriteColour: "Red" }

这显然没有好处。使用Facebook上的其他网站, 更改他们最喜欢的颜色, 向我的网络服务提出ajax要求, 是很微不足道的。

Option 2: On the server, extract the uid from a cookie: Is this even possible? I have read that Facebook sets a cookie containing the uid and access token but do I have access to this cookie on my domain? More importantly, can I securely extract the uid form the cookie or is this open to spoofing just like option 1.

Option 3: User server-side authentication on the server: I could use the server-side authentication to validate the user identity on my server. But will this work if I am already using client-side authentication on the browser? Will I end up with two different access tokens? I would like to make FB.api requests from the browser so I need the access token on the client (not just on the server).

这一定是个非常常见的假想,所以我认为我漏掉了一些基本的东西。我读过许多Facebook文件(各种认证流程、访问标记、签名请求等)和许多SO上的文章,但我还是不明白客户端认证和服务器端认证是如何很好地结合起来的。

简而言之, 我想知道服务器上的用户身份, 但仍向客户浏览器的 Facebook api 请求?

(我在服务器上使用 ASP. NET 和Facebook C#SDK)

< 强势 > EDIT < /强势 > : 增加的赏金。我希望得到关于如何处理这种情况的正式建议,甚至一个例子。如前所述,我已经阅读了许多关于认证流程的官方FB文件,但我仍然无法找到关于客户端和服务器端认证如何合作的确定性。

Answer 1

Option 1: The easiest way I can think of is to include the accessToken in JS and pass it with the ajax call.

Option 2: Using the same as option 1, but instead of sending just the accessToken, send the signedRequest.

在服务器一侧,您可以使用 (TryParse Trasser Signer Request 方法) 来解码它, 这将为您提供 UserID :-)

注意: 符号请求 用程序秘密加密。 < strong > you是唯一应该知道的人, 所以您在那个端上是安全的。

免责声明:

我没有在C#的编码经验, 但小小的搜索谷歌给了我这个:

"http://csharpsdk.org/docs/web/"rel="nofollow">脸书C#SDK为 ASP.NET

进行AJAX请求

Answer 2

其实很简单

When the user loads you app use the server side authentication, get the access token and load the user data by issuing an api request from the server.
On the server side you ll have everything you need and it s sandboxed.

When the page renders for the user, using the js sdk get the user authentication data, you should be able to use FB.getLoginStatus since the user already went through the server side authentication.
Now on the client side you also have an access token which you can use to get the user data from the graph api.

The two tokens will be different, and will also have different expiration, but that should not be a problem, both token should work properly as you d expect them to.
Since both sides have their own token and a way to make requests to the api, there s no need to send any fb data between them.

所以,你说的第三种选择,对我来说, 听起来是最好的, 并且它真的很简单实施这一点。

Edit

All facebook SDKs are just wrappers for http request since the entire fb api is made on http requests.
The SDKs just give you easy and shorter access to the data with out the need to build the url yourself (with all the different possible parameters), make the request and parse the response.

To be completely honest, I think that stop providing a way for the C# SDK to support server side authentication is a very bad decision.
What s the point in providing a SDK which does not implement the entire api?

The best answer to your question, from my experience, is to use both server and client side authentication, and since the C# SDK does not support it, my advice to you is to create your own SDK.
It s not complicated at all, I already implemented it for python and java (twice), and since you ll be developing it for your own needs it can be tailored for your exact needs, unlike a public SDK which should support all possible options.

2nd Edit

不需要创建全新的 SDK, 您可以只“ 扩展” 您正在使用的内容, 并添加您需要的缺失部分, 比如断开侧侧认证支持。

Answer 3

我不知道它是否具体针对语言,但使用服务器和客户端认证并无害。

你可以研究选择2,但是是的,那也很容易被欺骗。

选择方案3,你将有一个用户会话的单一存取标记, 所以我认为这是最好的选择, 因为在从客户方面传递用户信息时, 你总是有机会骗取用户信息。

Answer 4

我最近也有同样的问题。选择2, 请查< a href="https:// developmenters.facebook. com/blog/post/534/" rel="nofollow",

说实话,我不够黑客知道你能否在饼干里打出UID, 但是这似乎是一种正式的方式。

EDIT:关于选项2下的另一个问题,是的,我认为你必须访问你域上的这个饼干。

Edit

2nd Edit

友情链接