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.

Starting March 10th, The POST for canvas option will become mandatory for all Facebook canvas apps. This means all requests to your iframe originating from the Facebook frame will be POST requests. If you use restful controllers in your app, this is not a good news. Fortunately, there is a very easy way to convert those POST back to GET with a Rack middleware :

Since all request coming from Facebook will include a signed_request parameter, you can assume that these requests are coming from the top frame. Other requests made directly from your iframe won’t be altered. You can safely now safely use Post for canvas and continue to assume all requests coming from the top frame will be get requests.

With Poll for Facebook, you can add as many questions as you want to your poll, images and invite your friends to answer it. There is a free and a Premium version.

I encourage you to try it and give me your feedback. It is now available in English, French, Spanish and German.

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!