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

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

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

The only case where this is an issue is if they''ve granted cookie  
access on
a site-by-site basis, since you can''t use facebook without allowing  
cookies
(or at least that has been my experience).

I don''t think this should be a priority, since your typical facebook  
user will
just allow cookies globally.

On Jan 28, 2009, at 6:33 PM, Aaron Nemoyten wrote:
>
> 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

Check out Safari cookie preferences and you''ll see that the default
option is Accept Cookies:  Only from sites you navigate to.
In Firefox the default equivalent is Accept Third Party Cookies.

If an iFrame is in a different domain from the top site, cookies will not be
accepted if these options are turned off.

Facebook itself will work just fine, but any iframe content from a different
domain will have no cookie access.

I may have come up with a solution for my current issues that just ignores
cookies all together.  Sadly, this may be the only choice if I want complete
reliability.



----- Original Message ----
From: kevin lochner <klochner at gmail.com>
To: Aaron Nemoyten <swivelmaster at yahoo.com>
Cc: facebooker-talk at rubyforge.org
Sent: Thursday, January 29, 2009 11:02:42 AM
Subject: Re: [Facebooker-talk] Fwd: [rfacebook] Re: How exactly are session
cookies supposed to work? Will ensure_authenticated use them?

The only case where this is an issue is if they''ve granted cookie
access on
a site-by-site basis, since you can''t use facebook without allowing
cookies
(or at least that has been my experience).

I don''t think this should be a priority, since your typical facebook
user will
just allow cookies globally.

On Jan 28, 2009, at 6:33 PM, Aaron Nemoyten wrote:
> 
> 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

We set cookies on the initial request to the iframe. Does that cause  
problems?

Mike

On Jan 29, 2009, at 2:20 PM, Aaron Nemoyten wrote:
> Check out Safari cookie preferences and you''ll see that the
default
> option is Accept Cookies:  Only from sites you navigate to.
> In Firefox the default equivalent is Accept Third Party Cookies.
>
> If an iFrame is in a different domain from the top site, cookies  
> will not be accepted if these options are turned off.
>
> Facebook itself will work just fine, but any iframe content from a  
> different domain will have no cookie access.
>
> I may have come up with a solution for my current issues that just  
> ignores cookies all together.  Sadly, this may be the only choice if  
> I want complete reliability.
>
>
>
> ----- Original Message ----
> From: kevin lochner <klochner at gmail.com>
> To: Aaron Nemoyten <swivelmaster at yahoo.com>
> Cc: facebooker-talk at rubyforge.org
> Sent: Thursday, January 29, 2009 11:02:42 AM
> Subject: Re: [Facebooker-talk] Fwd: [rfacebook] Re: How exactly are  
> session cookies supposed to work? Will ensure_authenticated use them?
>
> The only case where this is an issue is if they''ve granted cookie
> access on
> a site-by-site basis, since you can''t use facebook without
allowing
> cookies
> (or at least that has been my experience).
>
> I don''t think this should be a priority, since your typical
facebook
> user will
> just allow cookies globally.
>
> On Jan 28, 2009, at 6:33 PM, Aaron Nemoyten wrote:
>
>>
>> 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
>
>
>
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
--
Mike Mangino
http://www.elevatedrails.com

The assumption that it worked is what is causing the problems :)

I just tried out a proof of concept that avoids cookies completely.  

Here''s the gist of it:

application.rb:
  def authenticate_with_session_id_only
    if params[:mc_session_id]
      set_facebook_session
CGI::Session::ActiveRecordStore::Session.find_by_session_id(params[:mc_session_id]).data[:facebook_session]
    else
      render_javascript_redirect
    end
  end

Facebooker''s controller.rb
 def set_facebook_session provided_session = nil #! added
        returning session_set = use_provided_session(provided_session) ||
secure_with_facebook_params! || secure_with_token! || session_already_secured?
|| secure_with_cookies!  do #! switched order, added provided_session
          if session_set
            capture_facebook_friends_if_available! 
            Session.current = facebook_session
          end
        end
      end

      def use_provided_session p
        @facebook_session = p if p
      end

Then I''m passing around a parameter that has the session key but with
our own name - mc_session_id - in link_to tags and (pending implementation over
the next hour) from Flash.

-Aaron




----- Original Message ----
From: Mike Mangino <mmangino at elevatedrails.com>
To: Aaron Nemoyten <swivelmaster at yahoo.com>
Cc: kevin lochner <klochner at gmail.com>; facebooker-talk at
rubyforge.org
Sent: Thursday, January 29, 2009 1:20:47 PM
Subject: Re: [Facebooker-talk] Fwd: [rfacebook] Re: How exactly are session
cookies supposed to work? Will ensure_authenticated use them?

We set cookies on the initial request to the iframe. Does that cause problems?

Mike

On Jan 29, 2009, at 2:20 PM, Aaron Nemoyten wrote:
> Check out Safari cookie preferences and you''ll see that the
default option is Accept Cookies:  Only from sites you navigate to.
> In Firefox the default equivalent is Accept Third Party Cookies.
> 
> If an iFrame is in a different domain from the top site, cookies will not
be accepted if these options are turned off.
> 
> Facebook itself will work just fine, but any iframe content from a
different domain will have no cookie access.
> 
> I may have come up with a solution for my current issues that just ignores
cookies all together.  Sadly, this may be the only choice if I want complete
reliability.
> 
> 
> 
> ----- Original Message ----
> From: kevin lochner <klochner at gmail.com>
> To: Aaron Nemoyten <swivelmaster at yahoo.com>
> Cc: facebooker-talk at rubyforge.org
> Sent: Thursday, January 29, 2009 11:02:42 AM
> Subject: Re: [Facebooker-talk] Fwd: [rfacebook] Re: How exactly are session
cookies supposed to work? Will ensure_authenticated use them?
> 
> The only case where this is an issue is if they''ve granted cookie
access on
> a site-by-site basis, since you can''t use facebook without
allowing cookies
> (or at least that has been my experience).
> 
> I don''t think this should be a priority, since your typical
facebook user will
> just allow cookies globally.
> 
> On Jan 28, 2009, at 6:33 PM, Aaron Nemoyten wrote:
> 
>> 
>> 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
> 
> 
> 
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
--
Mike Mangino
http://www.elevatedrails.com

On Thu, 2009-01-29 at 16:20 -0500, Mike Mangino wrote:
> We set cookies on the initial request to the iframe. Does that cause  
> problems?
> 
Yes.  IE6 and Safari have default behavior disabling cookies in an
iframe.

I create a facebook session on the first page the same way you would
secure from a profile, then the tomfoolery begins.  I reset the session
in case they had a session at www.  Each page is foo.iframe, so I can
key off the page format as iframe.  I''ve also written something named
the "stash" where you throw data like a session- some of the methods
like current_user test for iframe format and fetch the user from the
stash or session based on that.

The stash idea isn''t the most secure- it''s pretty much a
session-in-the-url trick.  A key is passed on every request (but there
are helpers for that).  It''s at least secured by IP and expiry.

It''s a pretty seem-less system now that it''s in place.  But
yes, you
cannot reliably use cookies (and therefore the rails session) in an
iframe.

-- 
Matthew Beale :: 607 227 0871
Resume & Portfolio @ http://madhatted.com
> Mike
> 
> On Jan 29, 2009, at 2:20 PM, Aaron Nemoyten wrote:
> 
> > Check out Safari cookie preferences and you''ll see that the
default
> > option is Accept Cookies:  Only from sites you navigate to.
> > In Firefox the default equivalent is Accept Third Party Cookies.
> >
> > If an iFrame is in a different domain from the top site, cookies  
> > will not be accepted if these options are turned off.
> >
> > Facebook itself will work just fine, but any iframe content from a  
> > different domain will have no cookie access.
> >
> > I may have come up with a solution for my current issues that just  
> > ignores cookies all together.  Sadly, this may be the only choice if  
> > I want complete reliability.
> >
> >
> >
> > ----- Original Message ----
> > From: kevin lochner <klochner at gmail.com>
> > To: Aaron Nemoyten <swivelmaster at yahoo.com>
> > Cc: facebooker-talk at rubyforge.org
> > Sent: Thursday, January 29, 2009 11:02:42 AM
> > Subject: Re: [Facebooker-talk] Fwd: [rfacebook] Re: How exactly are  
> > session cookies supposed to work? Will ensure_authenticated use them?
> >
> > The only case where this is an issue is if they''ve granted
cookie
> > access on
> > a site-by-site basis, since you can''t use facebook without
allowing
> > cookies
> > (or at least that has been my experience).
> >
> > I don''t think this should be a priority, since your typical
facebook
> > user will
> > just allow cookies globally.
> >
> > On Jan 28, 2009, at 6:33 PM, Aaron Nemoyten wrote:
> >
> >>
> >> 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
> >
> >
> >
> > _______________________________________________
> > Facebooker-talk mailing list
> > Facebooker-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/facebooker-talk
> 
> --
> Mike Mangino
> http://www.elevatedrails.com
> 
> 
> 
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk