Cookies and Facebook canvas apps

With the new Facebook way of loading iframes apps with POST requests, the safari third-party cookie problem is now partly fixed. It has always been a big headache dealing with cookies on the Facebook platform since Safari rejects them by default. With POST requests however, it is now possible to set cookies from the server. It seems Safari will still reject cookies set from the client.

So if you are using the Facebook Javascript SDK and set the cookies option to true, Safari won’t accept the FBS_XXXX cookie planted by the SDK. I struggled a whole week-end before figuring it out.

The work-around I use is to set a cookie from the server with the signed_request in it if there is one present. This solves most of the problems since I can just use the cookie when I don’t have a fresh signed_request (this happens when I do a request inside the canvas).

Here is the code inside a before_filter in the application_controller. I use Rails with the Facebooker2 gem :

The P3P header is used to make IE6 and IE7 accept the cookie as well.

If you’re building a Facebook canvas application with Rails, take the time to also read my post about keeping your REST architecture with the POST requests.

Rails geopositioning with Google Maps

A common problem when building a Rails web application that deals with addresses is geopositioning. Geopositioning can have different meaning depending on what you’re trying to achieve. In this article and the following, I will describe my solution to the following problems :

1. The user enters an address and you need to validate it and geoposition it (latitude & longitude) on a map.
2. You need to display the google map for that given address on a webpage.

Today, I will show you how I did the first step using the YM4R/GM plugin.

1- Setup the plugin and get you Google Maps key

First thing to do is to install the YM4R/GM plugin plugin. There is also a gem but it seems to be a stripped-down version of the plugin. I couldn’t get it working so I would advise to use the plugin :

script/plugin install svn://rubyforge.org/var/svn/ym4r/Plugins/GM/trunk/ym4r_gm

The plugin creates a file in your config folder named gmaps_api_key.xml. You need to enter your Google Maps API keys for the different environments. You can get the keys here.

2- Create the model

Next thing to do is to create your Geolocation activerecord model. You need to at least have those four attributes :

create_table "geolocations", :force => true do |t|
  t.string   "address"
  t.string   "city"
  t.float    "latitude"
  t.float    "longitude"
end

You might also want to add the country and postal code to the mix. But in most case, Google Maps will be able to return you a location with just a street address and a city.

3- Set the geolocation on the before_save

When you create a new gelocation record, you want to geoposition it. Here’s my code in the Geolocation.rb model :

before_save :set_geolocation

def set_geolocation
  if changes['address'] || changes['city'] || !mapped?
    results = Geocoding::get(complete_address)
    if results.status == Geocoding::GEO_SUCCESS
      self.latitude, self.longitude = results[0].latlon
    else
      self.latitude, self.longitude = nil
    end
  end
end

def complete_address
  [address, city].select(&:present?).join(', ')
end

def mapped?
  latitude && longitude
end

What this does is set the latitude and longitude for the given address on the before_save callback. We first check if the address or the city changed and if so we try to get a geocoding. If the API responds with SUCCESS, we set the latitude and longitude with the first result. If the API failed to return a valid address, we set the latitude and longitude to nil. We can check if the address was mapped using the mapped? method.

4- Wrap it up

Geopositionning the address is only the first part of the problem. Next week I’ll show you how to use the latitude and longitude information we stored to display Google maps in your webpages.

Next week : How to display a google map for a geopositioned address

Speeding up Tunnlr

When developing a Facebook or Facebook Connect application, there are times when Facebook servers will need to directly make requests to your application. This means your local web server has to be remotely accessible for incoming requests.

Typically, when working locally, your mongrel or webrick instance running on port 3000 is not accessible unless you enable port forwarding on your router. And even then, your ISP probably doesn’t assign you a fixed IP address which means you have to run a dynamic IP address service like dyndns. This quickly gets complicated and if you work behind a corporate network or develop from different locations (ex.: home, office, Starbucks…), this solution won’t even work.

Meet Tunnlr, an easy to use service that makes your local Rails server accessible from the Internet by just typing a single rake command in your console. When you register to the service, you will be assigned a fixed URL address with a port number and this is the address you will use to configure your Facebook application and access it locally.

One downside to that approach is that since each request has to do a return trip to the Tunnlr servers, you loose the lightning speed loading time you’re used to when developing from your local machine (no network latency). I found a little hack that will bypass the need to do a return trip and it can be done in three easy steps

1- Modify your /etc/hosts file and add the following line :

127.0.0.1	web1.tunnlr.com

This tells your machine to route all requests made to the web1.tunnlr.com address to your local machine. Unfortunately, there is no way to specify port redirections in the hosts file so we need step 2 and 3 to make sure our remote and local ports are the same.

2- Modify your tunnlr.yml or facebooker.yml file to make your local port the same as your remote port. In my case, this is port 10524.

remote_port: 10524
local_port: 10524

3- Start your Rails server with the same port that has been assigned to you by Tunnlr.
[/code]script/server -p 10524[/code]

That’s it! Now when you query web1.tunnlr.com your local requests will stay local and your server will still be remotely accessible from the tubes!