Monday, October 22nd, 2007...10:27 pm
The low-down on Facebook sessions
Jump to Comments
I hang around in the #facebook channel on freenode, and a question that recurs a lot is to do with session keys. Now, those are explained in the Facebook developers wiki, but not particularly well. This is probably why this question pops up a lot.
Here’s the clear, definitive guide to sessions in facebook.
There are two main kinds of apps that you can build for Facebook:
1. Web applications
2. Desktop applications
Web applications
Web applications are “normal” facebook apps, the kind you add to your profile. They run entirely within facebook’s confines (though they can do so as part of facebook - also known as an FBML apps - or within an external iframe). Examples: Top Friends, Vampires, SuperWall, etc.
These are the easiest apps with which to handle sessions. Here are the key facts you need to know:
1. When redirecting the user to add your app, redirect them to your add/install URL, not to your login URL. (in rfacebook, use :require_facebook_install, not :require_facebook_login) This will display the page with a lot of checkboxes to your users.
2. Every user who has added your app automatically provides you with an infinite session key valid until that user removes your app. Save that key.
3. That session key, combined with the facebook uid, can be used to activate a facebook session which you can then use to do whatever you need to that user.
So the key development step is to pull out that session key and uid as soon as you can, since those are the handles with which you’ll be manipulating that user’s profile, friends, information, etc.
That’s it. That’s all there is to it. All the rest of the session-related noise on the wiki can be ignored. However, if you’re still curious, please read the note at the bottom of the article.
Desktop applications
Desktop applications are separate from facebook, but using a facebook login and, on occasion, interacting with the user’s facebook profile. A facebook widget on your Mac OS X dashboard is an example of an external application. If you’re building one of these, you probably know all this already. All the noise about infinite sessions is actually for your benefit.
Here are the key facts:
1. Get your users to login to facebook by forwarding them to your login URL. (in rfacebook, use :require_facebook_login) This will display the page with only 2 checkboxes.
2. If they click both checkboxes on the login page, then you do have an infinite session key for that user. You can find out if it’s infinite by checking the fb_sig_expires fbparam. If it’s 0, the key is infinite.
3. You don’t need a user’s key in order to grab stuff from their facebook profile. You don’t even need it to change their profile, if somehow they have decided to add a profile box for your app (it does not get added automatically by logging in!). What you do need is one of them infinite session keys
Infinite session keys
Both desktop and web applications effectively use infinite keys. If you’ve been following, you now realise that a web app doesn’t need to worry about it, though, since all added apps automatically get infinite keys for all their users. Desktop applications, however, need to do something explicit to get that key. Here’s what:
1. Create a user with a normal sounding name, that you will use as your infinite session key user. Make sure he’s got access to your app (in case you’re in developer mode). You don’t want to use a real user for this because of the risk that that user might inadvertently remove your app, perhaps as part of a badly thought out test.
2. Log in to your app, making sure to click both checkboxes.
3. Print out the session key for that session. Save it. Treasure it. It’s your infinite session key.
Make sure you never ever screw around with that user or else all your update processes will come tumbling down, since they all rely on that key being permanent.
Closing words
There’s one thing that you might realise upon reading this: the session key is completely and utterly redundant. I have no idea why Facebook decided it was necessary. It is an extra hurdle for developers to jump over. It adds nothing, since:
1. Facebook already knows it’s you interfacing with it, since you’re providing it with your api key and secret
2. Facebook knows which users have added your app and can use that to determine whether you should have access to it
So yes, the session key is pointless. But you have to do it.
That’s it for the facebook session key. Hopefully this clears some of the dust around this very simple, but oft-repeated question: “Session key? WTF?”.
Note to web app developers: Someone pointed out that saving each user’s session key is not necessary for many web apps. That is true. However, at the same time:
1. It could become necessary at some point, since certain actions require the user’s facebook session key, so might as well do it now
2. It’s simpler to understand that you must save the session key for each user than to have to go through the whole “how to generate your very own infinite session key” rigmarole.
17 Comments
October 28th, 2007 at 6:37 pm
Hey,
I’m working on a desktop app and want to get an infinite session. When you say “Create a user with a normal sounding name, that you will use as your infinite session key user.”
Do you mean to actually register a new account on Facebook and use the infinite session key for that user as a key that can be used for other users who have added your app?
Thanks
October 28th, 2007 at 8:10 pm
Tyler:
Yes, that’s what I meant. The reason it’s good to create a completely separate user is that then you will decouple yourself from any risk that somehow you mistakenly invalidate your infinite session key, e.g. during testing, by removing and adding the app. In a desktop app, you’ll be doing most things through the infinite session key, so it’ll break your whole app if it becomes invalid.
Bear in mind that Facebook officially does not support what they call “fake users”. So be sure to make that user look like a real user so it doesn’t get deleted by Facebook a few months down the line. That means, don’t call it “My App User”. Call it something like Steve Johnson or something.
Some people on #facebook advocate using your own user to set up your infinite session key, but I found it broke quite often due to some testing. It’s up to you, really.
Hope this helps.
November 2nd, 2007 at 10:22 pm
Hey Daniel,
I was able to get my infinite session key, thanks for the help.
I’m using the Java Client Library (which I’ve heard is terrible), but I’m having a bit of a problem actually using the key. I’ve grabbed the key and saved it, now when I create a new FacebookRestClient I pass the infinite key as a parameter to the constructor (instead of getting the session key by launching the browser). It keeps telling me that me key is either expired or invalid, or that my signature is incorrect.
I don’t suppose you have any experience with this?
November 2nd, 2007 at 10:22 pm
BTW, you can respond by email if you prefer.
Thanks for the help.
November 12th, 2007 at 7:48 pm
One more clarification question: does rfacebook’s require_facebook_install save the returned infinite session key, or does one need to do that separately? If so, how does it subsequently get used by rfacebook?
November 13th, 2007 at 1:42 am
I think I can answer my own question. From the code, it looks like require_facebook_install doesn’t do anything to preserve the session key.
However, calling activate_with_previous_session and passing it the current fb_sig_session_key seems to work just fine. Doing this before calling require_facebook_install also avoids “already installed” complaints out of the F8 API under certain conditions.
I’m still not certain why one needs to “save” the session key IFF the app is a webapp. In it is installed, F8 will always start the app, and hence on the first callback, seems like there will always be an infinite session key available to send into activiate_with_previous_session.
BTW thanks for this write-up, Daniel. Best one out there I’ve seen on a very important topic to everyone.
November 13th, 2007 at 2:36 pm
Thanks. I hoped it would be useful when I wrote it :-)
You need to save the session key and uid so that you have a handle to get back to your users and, for instance, update their profiles, outside of a request/response context.
I’ll probably write an article about this sometime, but one of the key architectural decisions I made when designing our facebook app was to move the profile and action updates off the request/response path (i.e. have them running in a background process). For this, you *need* the session key and uid to be saved in a table somewhere.
The point, really, is that it’s quite easy to save the key/uid, and having them saved has large potential benefits if you decide to alter the architecture of your app. So you might as well save them!
November 18th, 2007 at 5:39 am
Do you have any code that shows the work flow for using :require_facebook_install. I am trying to write a sample app.I have not published. But I wanted to test to see how this app can be added by another user. How do I do that? Also it gives me an error “You must activate the session before using it.”
November 29th, 2007 at 7:50 pm
I’m running into an issue where facebook is telling me that some of the session keys that i store for users are invalid. (Interestingly, the only one that works is the one for MY user id)
None of my users (or myself) are checking the ‘keep me signed in’ check box that is shown upon adding the application… Is this necessary for the stored session keys to work?
November 29th, 2007 at 9:16 pm
stridie:
If your application is external, then yes, they need to check the second box for their session to be infinite. In that case, fall back to your own infinite session key.
If, on the other hand, your app is the kind that lives on Facebook itself rather than externally, then you should switch from requiring the ‘facebook login’ to requiring ‘facebook install’, however that’s done in the technology you’re using. The way to do it in RFacebook is to switch from:
before_filter :require_facebook_login
to:
before_filter :require_facebook_install
Hope this helps!
Daniel
November 30th, 2007 at 1:08 pm
hi, i m integrating drupal with facebook.
to start with i want to configure drupal to use facebook.
so i need userid as well as infinite sessionID so, how can i get that IDs.
plz help me.
thanks in advance…….
December 3rd, 2007 at 5:06 am
Hi Daniel,
Why do you suggest persisting sessionkey/user_id pairs? Assume I persist them into a table — however in order to use the table I’d have to get user_id through facebook login redirect anyway. Then the quesions is whether I get the sessionkey from my table or again from facebook.com. I can see some perf improvement from getting key locally, but that’s pretty much it, the downside is managing an extra table and potential sync issues.
Also you suggest redirecting to install URL — it works great for non-app-users by bypassing login page. However the users who already have that app installed and click on that link are seeing a page telling them that the app is already installed. (redirecting to login URL causes nested iframe though with all of facebook appearing inside of app frame and then surrounded by original facebook frame ;-)
Thanks!
– Andrey
December 3rd, 2007 at 10:09 am
Andrey:
1) You need the session key and uid to do stuff to the user when they’re not logged in (e.g. when one of their friend’s actions causes an update to be required on their profile). This has nothing to do with performance.
2) Requiring install and just plain redirecting to install are two different things. Only redirect to the installation page if the user has not already added the application. In RFacebook, that’s done with:
before_filter :require_facebook_install
With this, the user will only be redirected to the install page if they have not already added the app.
Daniel
December 4th, 2007 at 4:24 am
Daniel,
Thanks for the reply.
1) makes sense. For my app is not quite applicable as I store _all_ of user data created by my app in my database, hence if a logged in user A does an action that changes some data of not-logged-in user B, I do not need a session to manipulate user B data (user B data is stored in my local tables, and all I need is his userID).
Regarding (2) I am using asp.net and I have fixed the error that I have had — I think conceptually it does what you suggest to do with RFacebook.
Cheers,
– Andrey
January 4th, 2008 at 9:10 am
Hi we are having MASSIVE problems with the session ID stuff
Forbidden
You don’t have permission to access /index.phphttp://’Our IP Address’/get_infinite_key.php on this server.
does this get_infinite_key.php file need any other permissions?
I followed the instructions from this site
http://wiki.developers.facebook.com/index.php/Infinite_session_howto#Step_1:_Add_your_application
But we cannot understand why it wont work
PLLLLLEASE HELP!!!!
January 4th, 2008 at 9:39 am
Jason, this looks like a PHP issue rather than a Facebook issue. Go on the #php channel on irc.freenode.net and ask for help there, they’ll show you how to get your server working properly.
February 18th, 2008 at 7:23 pm
Hi Daniel,
Excellent article and this stuff works. I am not clear about one thing, however, which is - can a user’s infinite session key help him get his friend’s friends or his friend’s profile ?
Will appreciate what you have to say about it. Does $facebook->set_user(my_friend_id, my_session_key) and then $facebook->api_client->friends_get( ) get my friend’s friends ?? I am not sure this happens.
Leave a Reply