Dynamic Tunneling for Your Facebook App

When I was launching Forgiveness, my first attempt at a Facebook App via RoR, I ran into one of the typical developer quandries. How do I debug this thingy I’m building?

I sought advice from Steve Enzer, and his answer was ‘create a separate FB App id’. Yep, you can do that. I’m sure it works just fine. However, I wanted to come up with a single-App solution, you know, just because.

My App backbone was based upon Facebooker, a great gem for just such purposes. And assuming that you’re using that gem, you’re provided with:

% rake facebooker:tunnel:start

Which starts up the traditional server tunnel to your local dev box; Facebook’s proxy won’t know the difference. I’ve also set up my canvas page URLs and the like with a fixed IP – according to FB’s best practices, because they don’t want to deal with all the DNS resolution stuff – and it listens on port 80 with a dedicated context. So, I’ve got my facebooker.yml set up for port 3100:

tunnel:
  public_host: cantremember.com
  public_port: 3100
  local_port: 3100

And here’s my nginx config:

# # included into vhosts/localhost.conf (*.by-ip) # answers to :80 # # registered with FaceBook location /forgiveness { # no-trailing-/ case (the rewritten URI has a zero length) if ($request_filename = '') { rewrite (.*) $1/; } # the only way i could figure to get conditional proxying # proxy_pass via variables = no # if { proxy_pass } = no # so ... two more goofy contexts # magic tunnel cookie (any value) if ($http_cookie ~ '_forgiveness_tunnel=1') { # last : stop rewriting, but re-process through nginx (vs. break) rewrite /forgiveness(.*) /forgiveness-dev$1 last; } rewrite /forgiveness(.*) /forgiveness-pub$1; } location /forgiveness-pub { # root contextify # break to terminate re-processing through nginx rewrite /forgiveness-pub(.*) $1 break; proxy_pass http://cantremember_forgiveness_cluster; } location /forgiveness-dev { rewrite /forgiveness-dev(.*) $1 break; # same as public upstream proxy_pass http://127.0.0.1:3100; }

Here I omit the upstream cluster configs, and I’ll let the comments speak for themselves … I always try to keep track of red herrings at least at some level, and there were several I bumped into while trying out this solution. The best approach that I found was to simply set a cookie with a naming convention that nginx could parse (yes, there is a regex performance penalty here). The development context is routed locally, which is where the tunnel is waiting to pick up and run with it.

Setting the cookie, well that’s another trick. Though not much of one. Of course your App is completely masked behind the apps.facebook.com domain, so trying to set a cookie to your internal domain (eg. IP) through your browser isn’t so easy, and it’s repetetive manual work. So, just bake it into a dedicated action in your App:

# allows for Facebook pub / dev tunneling # have to set the Cookie within the scope of the app # can't use Firefox cookie editor to hack it def tunnel # how convenient! value = params[:id] # this is how we get pub / dev tunneling # see support/nginx if value == 'nil' cookies.delete :_forgiveness_tunnel else cookies[:_forgiveness_tunnel] = value end ###render :text => "OK #{value}", :content_type => 'text/plain' redirect_to root_url end

Then use /:controller/tunnel/1 to engage, and /:controller/tunnel/0 to disengage. A little bit of auth logic, and you’re good to go.

NOTE: If your screen reader is reading this, please contact me at admin@cantremember.com ... because it shouldn't. FIXME: build this dynamically based upon the maximum content in any sub-Element of this Element. I will call this my "Safari Reader Counterweight". In some of my Posts, I have huge code excerpts, etc. Safari Reader, at least in iOS, will identify the 'main Element', the one it features, based upon its content length. Sometimes those code excerpts get identified as the 'main Element', and the Post is borked in Safari Reader mode. This is a counter-weight; it gives the <main> Element additional content so that it gets featured, algorithmically. Yes, it increases the payload of every page (@see FIXME above). But not by that much. Then again, this is a guess as to how much content any given Element could contain. If it's not enough, BOOM, Safari Reader looks like crap. So, here's a great article on how to enable Safari Reader on your site. It's mostly guesswork, but those guesses helped me debug this obtuse goddamn problem. Oh, and look, you can enter and exit Reader programmatically. JavaScript can fix anything. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload.