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.
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.
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.