Tag Archives: gotchas

Gotchas of Authentication Flow for application on Facebook – OAuth 2.0 (2)

Facebook logo

/**

Vietnamese: bài viết này trình bày tiếp một số điểm có thể gây nhầm lẫn trong quá trình chứng thực Facebook OAuth 2.0.

**/

Following the first article, this one continue presenting about the cases that can make developers confused.

3. Big Facebook logo prevent redirection:

According to Facebook documents, the server must redirect users to “authorization page”  to grant permissions.

https://www.facebook.com/dialog/oauth?
client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=email,read_stream

But every redirect command sent from server leads to a blank page with a big blue Facebook logo instead!
If the same URL is put directly in a browser, then it goes to the correct page.

In short, Facebook has stopped the redirection from a third-party server. The user needs to redirect themselves, or we can help them by redirecting with javascript.

4. Tricky privacy settings:

One thing developers should know is that Facebook give full privacy control to the users. A user can change permissions any time they want. It means after a user approve your application, they still can:

  • Change their email, personal information
  • Choose to not provide you their real email, but a proxy email of Facebook
  • Remove some permission of your application (for example, publish feeds on wall)

Ofcourses, Facebook provides callback functions when those permissions change. However I don’t think it’s worth the efforts to handle all of these events, at least for a quick prototype application.

5. De-authorization callback

The authorization callback is the URL that Facebook will call if a user remove your application. At that time, the application should remove all user data that they save: access token, personal information…

At first glance, this seems to be a moral requirement. But in practice, obsolete data should not be kept anyway. Believe me, Facebook data flow is fragile, and you are asking for business logic troubles if not following the rule.

Gotchas of Authentication Flow for application on Facebook – OAuth 2.0 (1)

/**

Vietnamese: bài viết này trình bày một số điểm có thể gây nhầm lẫn trong quá trình chứng thực Facebook OAuth 2.0

**/

The Facebook Authentication Flow is rather complicated than it seems, and not very well documented. Here are some tips that maybe helpful if you are trying to make things work:

1. Notice parameters returned from Facebook:

  • code: When Facebook returns “code” parameter in Http request to your redirect URI, it means you need to use that code to request for access token.
  • signed_request: Signed request has several children parameters. An usual presumption is that this signed request always has Facebook ID of the current user. In fact it does if your application has already been authorized by that user. If not, you need to redirect the user to the giving-permission page.
  • request_ids: is used if your application has the “invite friends” functions. This is a comma-separated string (for example: “158187550924606,158187550924608,158187550924614″). Each number in that string is ID of an invitation sent (maybe by > 1 user). So we can say that a new user can accept the invitation of more than 1 Facebook user. In fact it is, since the app request may appears like “Viet X & Nam Y has invited you to use this app“. People often find it confused because they presume that a user can only be referred by only 1 user.

2. Always ask Facebook if your access token valid:

Even if you ask user to give “offline_access” right to your application, there’s a good chance that your stored access token will get expired. How do you know? Well, the only way available now is using your access token to request something, and if it fails, ask for a new one. That’s the way it works.

sometimes it’s hard to say a thing, though simple.

(to be continued)