[Facebooker-talk] Fwd: [rfacebook] Re: How exactly are session cookies supposed to work? Will ensure_authenticated use them?

[Aaron Nemoyten]

Hey everyone.

I'm the author of the original post to the Facebook/Ruby group.  I apologize for not getting over to this list sooner - Kevin Lochner emailed me and suggested it last week.

I'm trying to catch up on the discussion here.

Because the app I'm working on is in an iFrame AND we're using Flash AND we're relying on cookies to authenticate requests in Facebook...  we've had a lot of issues.

>> I don't know the best way to handle this because I don't know what  
> would cause the params[:fb_sig_session_key]
> to be blank in non-connect apps while the user is still logged in.   

The problem is navigation within iFrame apps - you get the fb_sig parameters and then you have one chance to initialize the session correctly...  the rest of the time you're basically flying blind.

This gets difficult because cookie settings vary from browser to browser, including Safari's very restrictive default behavior which prevents cookies from being set and read from within iframes that do not match the domain of the main tab URL.

Because Facebooker's default behavior is to initialize sessions from the session store BEFORE checking params, it's possible (and very easy) to end up with the wrong session if a user simply uses the app, logs out of facebook, logs back in, and uses the app again.

My easy fix to that was to make secure_with_facebook_params the first choice, followed by secure_with_token, followed by session_already_secured (and then cookies...  not sure how often we're even getting to that at this point).  Since these params should only come in once anyway, this isn't any more expensive and prevents the wrong session from being initialized.

There are still a ton of issues regarding cookie settings and setting/getting session.  I finally just figured out a problem we were having post-login/authorization in Safari that goes something like this:

* Application redirects user to login page
* Login page sends user to app with auth_token parameter
* Server initializes session with auth_token parameter
* Service sends response with cookies/session info included
* Browser refuses to set cookies but renders page
* Page has javascript to check for cookies and redirects top.href to href (my fix - this works when we have fb_sig params because we can recreate the session from them, set the cookies, and then redirect back into the frame)
* Params are included, including auth_token, which Facebook refuses to turn into a valid session because we already did that once (is this what's happening?) and an exception is thrown
* User sees error.

WARNING:  HORRIBLE HACK STARTS HERE!

The best fix I can come up with right now is to remove auth_token from the redirect to top, which will cause a redirect BACK to apps.facebook.com/appname, which will pass in fb_sig params but fail to create the cookie, so the javascript will redirect to top once again, but with fb_sig params in the url, which will create the session correctly with cookies allowed by all browsers, and redirect back into the frame.

So now the question is...  what if javascript isn't allowed to read the cookie in the first place.  Then maybe I have to have Flash ping the server (cookies are automatically sent with Flash requests) and let the server tell Flash if the cookie is correct, and then Flash can call ExternalInterface and force the reload.

...this is all to get around restrictive browser cookie settings.  The alternative is to just ask users to change their cookie settings and reload, but that seems like it would have a lower success rate.

-Aaron