Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with offline_access permission #13

Closed
wescarr opened this issue Jan 7, 2012 · 5 comments
Closed

Issue with offline_access permission #13

wescarr opened this issue Jan 7, 2012 · 5 comments

Comments

@wescarr
Copy link

wescarr commented Jan 7, 2012

If you request the offline_access permission, the python sdk will think the user is logged in while the Facebook JS API thinks otherwise if the user is not actually logged into FB. It appears that two additional cookies are set "act", and "csm" and are removed by the JS API when you call FB.logout(). The "fbsr_" cookie is NOT removed by the JS API if the user has granted the offline_access permission.

I'm not sure exactly what these cookies are used for, but it seems that the python sdk may need to know about them to be consistent with the JS API.

@martey
Copy link
Member

martey commented Jan 8, 2012

Are you saying that if you request offline_access, the access token retrieved with our code is different than one retrieving using Facebook's JavaScript methods?

@wescarr
Copy link
Author

wescarr commented Jan 8, 2012

I don't believe so, but it appears that the JS API does not solely look at the fbsr_ cookie to determine if a user is logged in. As I mentioned, the fbsr_ cookie remains with no expiration even after the user logs out of facebook. Perhaps this isn't an SDK issue, an our service needs to separately track if the user is actually logged in or not.

@wescarr
Copy link
Author

wescarr commented Jan 10, 2012

I think I did a poor job explaining the issue. Essentially it boils down to the python SDK not having the ability to tell if the user is actually logged into Facebook or not. Just relying on the fbsr_ cookie is not enough since it persists if your app has the offline_access permission.

To deal with this, I plan to rely on the JS API by calling FB.getLoginStatus() and then setting a separate cookie like fb_loggedin. Then on the server side, check for the presence of the new cookie as well as use get_user_from_cookie to determine if the user is logged in to Facebook.

Hopefully that clears things up a bit.

@martey
Copy link
Member

martey commented Jan 11, 2012

I took a cursory look at the PHP SDK and the Graph API documentation, and did not see any server-side method to retrieve a user's logged-in status.

As far as I can tell, the purpose of the fbsr cookie is to note that the user has a valid access_token, not that they are currently logged in. Since offline_access lets you use an access_token even if a user is not logged in, I assume that is why the fbsr cookie remains (although we might have a clearer answer once the cookies are properly documented).

I think using FB.getLoginStatus is probably the right move in this case, albeit not one that the Python-based SDK can take (since we can't assume that we will have access to JavaScript). I am leaving this open so that I (or someone else) can research it more (and hopefully confirm my findings), especially since it probably affects our django-facebook package.

@martey
Copy link
Member

martey commented Feb 18, 2012

I just checked the Graph API documentation, and am relatively certain that our current implementation is correct. Requesting offline_access means that you need to be able to use the Graph API regardless of whether the user is currently logged in to Facebook.

If your application is dependent on a user being logged in to Facebook, you should not be requesting the offline_access permission (which is deprecated anyway; see #19).

@martey martey closed this as completed Feb 18, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants