Comments misleading for routine 'get_user_from_cookie'

[collinsethans]

From the server side when you use the graph API for access_token, you get it irrespective of the fact whether the user is logged in or not.

Given this, the 3rd paragraph of this routine which mentions of returning a dict with uid and access_token only if the user is logged in is not right.

Correcting this will help new comers (like me) who read the code before adopting it.

Best,
Ethan

[martey]

I am not sure that I understand this.

If you are using server-side authentication, you should not be using get_user_from_cookie because that authentication method does not use cookies. Server-side apps should use get_access_token_from_code instead.

Let me know if I am missing something here.

[collinsethans]

I was probably not clear. I am using client-side auth and I meant the associated processing on the server side to get the access_token from the cookie.

[martey]

That clarifies things, but I still do not understand this issue.

The "fbsr" cookie is created and deleted by the JavaScript SDK. If the user has not authenticated with Facebook, the cookie will not exist, and get_user_from_cookie should return None. There should not be a situation where the "fbsr" cookie exists without the user having authenticated.

It would help if you could provide steps that explain how to reproduce this issue.

[collinsethans]

I think I am at wrong here. I was mentioning about the call for getting the access_token in lieu of the code. A couple of days back when I was manually testing the exchange process from a python shell, I had a test case where I log out before I call the get_access_token_from_code and that had worked. Today I tested it extensively and notice that it does not. Mostly I was doing something wrong previously to get the exchange done even when I was logged out, or probably fb was doing something wrong then.

So, effectively, there is no problem with the comment of get_user_from_cookie as I had mentioned initially. Sorry for the dead notice.