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.

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

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!

The Rails documentation states that this can be useful for forms that are triggered from multiple places.

In my case I needed it to redisplay the same page after a post that didn’t validate. I could redirect the user back to the right action but some request parameters were missing in the post action that prevented this to work right.

For example, if the last request was /my_action?location=there, I would lose the location parameter if I didn’t send it along in the post. And I didn’t want to send the parameter along since I was calling a different controller which business logic didn’t relate to these parameters.

Well, by using the HTTP referer, Rails redirects back to the URL with the right parameters and sends the user to the exact same location he was. Neat!