Inter-sections.net : Category facebook, everything about facebook

The low-down on Facebook sessions

Mon, 22 Oct 2007 22:27:00 +0000

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:

Web applications
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:

When redirecting the user to add your app, redirect them to your add/install URL, not to your login URL. (in rfacebook, use :requirefacebookinstall, not :requirefacebooklogin) This will display the page with a lot of checkboxes to your users.
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.
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:

Get your users to login to facebook by forwarding them to your login URL. (in rfacebook, use :requirefacebooklogin) This will display the page with only 2 checkboxes.
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 fbsigexpires fbparam. If it’s 0, the key is infinite.
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:

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.
Log in to your app, making sure to click both checkboxes.
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:

Facebook already knows it’s you interfacing with it, since you’re providing it with your api key and secret
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:

It could become necessary at some point, since certain actions require the user’s facebook session key, so might as well do it now
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.

Integration testing with rfacebook - solving the session problem

Sun, 21 Oct 2007 11:07:00 +0000

It’s always very important to write integration tests. Hell, it’s not just very important, it’s critical. Some systems make it easier than others to do so. Rails, for instance, provides many, many hooks and bits of framework to make your apps easily testable. Facebook, on the other hand, is a major pain in the ass.

One of the many ways in which Facebook (or more precisely, rfacebook) makes it difficult to write integration tests, is the session problem. Here’s how it goes:

You write your integration test, including a fresh set of fbparams to make the request pass through rfacebook’s requirefacebookinstall
It works, it passes, you’re happy and you buy everyone a round of drinks.
Some time later, for no apparent reason, your integration breaks and seems to think that your test fbparams don’t actually represent a valid user.
You shoot your coworkers after spending 3 hours trying to find what’s changed in your code to make it fail.

Now, we don’t want that, do we?

Symptoms

This is often visible through a spec failing with an error message something like:

  Spec::Expectations::ExpectationNotMetError: expected /Test message/, got "<html><body>You are being <a href=\"http://www.example.com/facebook\">redirected</a>.</body></html>"

After tearing your hair out just enough to make you look like a Benedictine monk, you’ll check the test.log file and find something like this:

Processing FacebookController#create_message_profile (for 127.0.0.1 at 2007-10-21 10:47:54) [POST]
  Session ID: 30f78183e4c851ef6af04c479bb34224
  Parameters: {"message"=>{"contents"=>""}, "post_form_id"=>"8a47588a90e2b89399aa4621eedaf9b4", "fb_sig_time"=>"1192733662.7756", "fb_sig_is_mockajax"=>"1", "fb_sig"=>"460d0402bf9475b18963ca8417a24a93", "action"=>"create_message_profile", "fb_sig_session_key"=>"<snip>", "fb_sig_profile"=>"<snip>", "controller"=>"facebook", "fb_sig_expires"=>"0", "fb_sig_added"=>"1", "fb_sig_api_key"=>"<snip>", "fb_sig_user"=>"<snip>", "fb_sig_profile_update_time"=>"1192638467"}
Can only render or redirect once per action
/Users/<snip>/Sites/<snip>/vendor/rails/actionpack/lib/action_controller/base.rb:714:in 'render_with_no_layout'
/Users/<snip>/Sites/<snip>/vendor/rails/actionpack/lib/action_controller/layout.rb:256:in 'render_without_benchmark'
/Users/<snip>/Sites/<snip>/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:50:in 'render'
...

At this point, you should be just about ready to go postal. If you are fortunate to work from home, like me, however, you don’t have any coworkers to shoot. This leaves you with only one option: figuring out what the hell is going on in there.

You might be tempted to try scraping a new set of test parameters from a “real” request to your system. If you do so, you’ll find that works. If you then play with which field exactly causes it to work again, you’ll find two fields must be updated in your test data for your integration test to work again: fbsig and fbsig_time. Since those fields are not actually required to create a new session, you might be inclined at this point to curse rfacebook. And, in a sense, you’d be right.

What’s actually happening in the guts of rfacebook is this: rfacebook not only checks that your session is valid. Before it even bothers doing that, it checks that your session parameters are consistent with each other. One of the checks is to see whether fbsigtime is less than 48 hours ago. If it isn’t, ie if your beautiful integration test has been running for a staggering two days, it will wipe all the fb_sig params, right away - which obviously causes issue when the rest of rfacebook tries to determine whether a user is logged in. This is what causes the redirect.

Here’s the guilty method:

    # Function: get_fb_sig_params
    #   Returns the fb_sig params from Hash that has all request params.  Hash is empty if the
    #   signature was invalid.
    #
    # Parameters:
    #   originalParams - a Hash that contains the fb_sig_* params (i.e. Rails params)
    #
    def get_fb_sig_params(originalParams)

      # setup
      timeout = 48*3600
      prefix = "fb_sig_"

      # get the params prefixed by "fb_sig_" (and remove the prefix)
      sigParams = {}
      originalParams.each do |k,v|
        oldLen = k.length
        newK = k.sub(prefix, "")
        if oldLen != newK.length
          sigParams[newK] = v
        end
      end

      # handle invalidation
      if (timeout and (sigParams["time"].nil? or (Time.now.to_i - sigParams["time"].to_i > timeout.to_i)))
        # invalidate if the timeout has been reached
        #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature was timed out"
        sigParams = {}
      end

      # check that the signatures match
      expectedSig = originalParams["fb_sig"]
      if !(sigParams and expectedSig and generate_signature(sigParams, @api_secret) == expectedSig)
        # didn't match, empty out the params
        #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature did not match"
        sigParams = {}
      end

      return sigParams

    end

Now, personally, I think that’s appalling behaviour for any code. It’s quietly swallowing one issue that it finds, “safe” in the knowledge that some other bit will break later because of this. In the realm of trying to stop developers from figuring out why their code breaks, this is pretty clever. Matt Pizzimenti must have a special deal with arms dealers located near technology hubs.

The solution

Now that we’ve found this awful piece of code, what can we do about it? We don’t want to just hack the gem and remove it, because god knows what might happen then. Who knows what other part of the code might blow up when we make such changes. Adding a special parameter to make it ignore fbsig and fbsig_time when that parameter is present would be a security issue. And anyway, the spirit of the code is right (checking session validity is a good thing), it’s just the implementation which sucks.

Turns out Ruby, with its wonderful dynamic aptitudes, provides more than enough rope to quickly hang rfacebook by the ear. You can overwrite that method from within your own code. This means that your integration tests will pass, and that your fixing code will never be overwritten by an rfacebook gem update - although it *is* possible that it would cause weird errors should Matt decide to change that method and move that check about. Hopefully he would make a specific announcement about that when releasing the update though.

To solve this issue, just add the following to your spec/story helper:

module RFacebook

  class FacebookWebSession
    def get_fb_sig_params(originalParams)

      # setup
      timeout = 48*3600
      prefix = "fb_sig_"

      # get the params prefixed by "fb_sig_" (and remove the prefix)
      sigParams = {}
      originalParams.each do |k,v|
        oldLen = k.length
        newK = k.sub(prefix, "")
        if oldLen != newK.length
          sigParams[newK] = v
        end
      end

      # # handle invalidation
      # if (timeout and (sigParams["time"].nil? or (Time.now.to_i - sigParams["time"].to_i > timeout.to_i)))
      #   # invalidate if the timeout has been reached
      #   #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature was timed out"
      #   sigParams = {}
      # end
      #
      # # check that the signatures match
      # expectedSig = originalParams["fb_sig"]
      # if !(sigParams and expectedSig and generate_signature(sigParams, @api_secret) == expectedSig)
      #   # didn't match, empty out the params
      #   #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature did not match"
      #   sigParams = {}
      # end

      return sigParams

    end
  end
end

Now you can have any fbsigtime and fb_sig you want in your integration tests. Best part is, it will only affect your tests - your production code will continue to check sessions correctly.

Specifying a before_filter and/or private method

Thu, 04 Oct 2007 13:12:00 +0000

How do you write specs for a private or protected method? Specifically (as this is often the case), how do you write a spec for a before_filter?

The answers that I found while looking online were not very explicit. The main points seemed to be “don’t test private/protected method”, “you should be specifying expected behaviours in the places where they’re used.” I decided to write this article to clarify how I’ve interpreted that advice.

Essentially, I decided to follow the advice given online. Don’t test the methods, test the behaviours you expect. Let’s take a simple example and see what this means in practice.

For our facebook application, I have a facebook controller which handles all the facebook posts (very RESTless, but that’s facebook for you!). There are two things that I want to see happen with every authenticated facebook action, and I’ve defined a filter for each of them:

class FacebookController < ApplicationController
  before_filter :require_facebook_install
  before_filter :set_user

  def index
    # ...
  end

  def other_action
    # ...
  end

private
  def set_user
    if @user = User.find_by_facebook_uid(fbparams["user"], :include => [:interactions])
      if fbparams["friends"]
        @user.cached_friend_uids = fbparams["friends"]
        @user.save
      end
      if fbparams["session_key"]
        @user.facebook_session_key = fbparams["session_key"]
        @user.save
      end
    end
  end

end

Now, requirefacebookinstall is given by RFacebook, so all I want to specify is that for certain actions, this filter must be called. All that it does is return true if proper parameters are included, that represent a valid facebook session. There’s a lot of those parameters, and I only use a few of them. The only time when I might want to have this filter return false is if I was testing what would happen with a blank session. However, this should never happen in my specifications, since I’m not trying to spec RFacebook, but my own code. This is the simple, shared spec that I wrote:

describe "Facebook Action", :shared => true do
  include FacebookControllerSpecHelper

  before(:each) do
    @controller.should_receive(:require_facebook_install).and_return(true)
  end

end

It’s not much to look at, and it doesn’t need to be! How to use it? Just include this (which I’d like to call a partial spec, but the rspec keyword is “shared”) into other specs:

describe FacebookController, "index page" do
  include FacebookControllerSpecHelper

  it_should_behave_like "Facebook Action"

  before(:each) do
    @user = User.create(:facebook_uid => 1)
  end

  def do_post
    post :index
  end

  it "should render the canvas" do
    do_post
  end

end

I can do this for any of the other facebook “pages”, of course. So far so good. Adding this “itshouldbehavelike” directive ensures that the filter is called for the actions where I specify that it needs to be called. Handily enough, this also removes the need for me to mock requirefacebook_install in every one of those specs, since it’s mocked just once in the shared spec.

How about setuser? That’s a little bit more tricky. In this case, I have actually written setuser myself, so I need to specify it. But I can’t! It’s a private method, therefore invisible to my specs! Oh dear. Let’s go back to the initial advice. Don’t specify methods, specify behaviours where they’re used. Okay. Thinking about it on a basic level, this makes sense. I do want to specify that my filter is working for each of the actions I’ve told it to work for. One way to do this would be to specify that set_user must function properly in each of those actions. The smart way is of course to put that into a partial spec as well.

describe "Facebook Action With User", :shared => true do
  include FacebookControllerSpecHelper

  before(:each) do
    @user = User.create(:facebook_uid => valid_fbparams["user"])

    @controller.should_receive(:fbparams).at_least(:once).and_return(valid_fbparams)
    User.should_receive(:find_by_facebook_uid).at_least(:once).and_return(@user)
  end

  it "should call set_user" do
    do_post
  end

  it "should save the user's cached friends" do
    @user.should_receive(:cached_friend_uids=).with(valid_fbparams["friends"])
    @user.should_receive(:save).at_least(:once)

    do_post
  end

  it "should save the user's session key" do
    @user.should_receive(:facebook_session_key=).with(valid_fbparams["session_key"])
    @user.should_receive(:save).at_least(:once)

    do_post
  end
end

Those are the three things I expect my setuser beforefilter to do for me. So now I can include them in my controller action spec as well!

describe FacebookController, "index page" do
  include FacebookControllerSpecHelper

  it_should_behave_like "Facebook Action"
  it_should_behave_like "Facebook Action With User"

  def do_post
    post :index
  end

  it "should render the canvas" do
    @controller.instance_variable_set(:@user, @user)
    do_post
  end

end

And that’s all. The best part is, including the “Facebook Action With User” behaviour automatically mocks that part of the process for me in all the actions where I put it, so that I don’t need to do it again and again. By extracting those apparently intractable filters into their own shared spec, I’ve not only managed to spec them, but I’ve also reduced the clutter in my mocking code. I now only mock the things which are relevant to the current action, instead of having to mock everything to “make things work”.

On the downside, by DRYing up this code it’s become a tad harder to follow at a glance, but I think it’s more readable once you’ve figured out what the included shared specs provide.

One final caveat: if you mock something in your shared specs, don’t mock it again in your concrete specs. Otherwise, you will get errors about your shared spec being broken.

I hope you found this article useful. Please feel free to leave a comment below if you agree or disagree with this method - particularly if you have something better to suggest!