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

[Mike Mangino]

Aaron, thanks for the note.

I like the idea of using params as the default choice. I think that  
definitely makes sense.

The post login authorization issue is really ugly. Are you able to get  
a canvas url for the post login url? That would be a cleaner way to  
solve the problem.

Mike

On Jan 28, 2009, at 6:33 PM, Aaron Nemoyten wrote:

> 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
>
>
>
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk

--
Mike Mangino
http://www.elevatedrails.com