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

kevin lochner klochner at gmail.com
Sat Jan 24 11:43:02 EST 2009 

Vince -

The cookies should disappear on the first request after the user has  
logged
out of facebook, because your app will only see them if facebook sets  
them
on each request.

I'm going to revert the secure_with_cookies! method
to no longer set session[:facebook_session], so the only time you  
would get
a state mismatch would be if the user logged out of facebook and hadn't
issued a new request to your site yet.

Are you seeing cookies persist for multiple requests after the user as  
logged
out of facebook?  Can you give an accounting of how your user's login
state is validated when there is an error?
(values of cookies, session, valid_session_key, key. expired, etc)

- kevin

On Jan 24, 2009, at 3:02 AM, vincent chu wrote:

> Kevin and Mike --
>
> I've been playing around with Connect in the past few days and have
> encountered similar problems. If I have a fb_connect view, cookies
> that hang around after the user has logged off will cause the app to
> fail when I try and access some user information.
>
> I think the problem comes back to the 'set_facebook_session' --- when
> a user comes in with cookies or with a facebook_session in his
> session, Facebooker will go ahead and create a new facebook_session or
> use the currently set one without checking to see if the session is
> truly valid.
>
> This is because the secure_with_cookies! and session_already_secured?
> methods never actually query facebook to check if the session_key that
> comes from the user's session or his cookies is actually valid.
>
> To get around this, I think the best thing to do is to maybe stick a
> small bit of code into the 'set_facebook_session' that checks to see
> if the user actually has a valid session. I stuck a begin/rescue block
> that does this (posted at gist.github.com):
>
> http://gist.github.com/51380
>
> Do y'all think this is a reasonable solution?
>
> Cheers,
>
> Vince
>
>
>
> On Fri, Jan 23, 2009 at 12:21 PM, kevin lochner <klochner at gmail.com>  
> wrote:
>> I agree with that - validating the cookies is an inexpensive call  
>> to make,
>> and
>> the fields that get serialized are in the cookies anyway.
>>
>>
>> On Jan 23, 2009, at 1:49 PM, Mike Mangino wrote:
>>
>>> We could go back to not storing the facebook session in the  
>>> session when
>>> it comes from a cookie. That seems reasonable to me.
>>>
>>> Mike
>>> On Jan 23, 2009, at 1:08 PM, kevin lochner wrote:
>>>
>>>> See below for a message I picked this up on the rfacebook google  
>>>> group
>>>> mailing list.
>>>>
>>>> I'm concerned with whether session_already_secured? is an accurate
>>>> indicator
>>>> of facebook connection status.    Bear with me while I step  
>>>> through the
>>>> logic, where
>>>> I've included just the meat of the functions below:
>>>>
>>>> session_already_secured?
>>>>> (@facebook_session = session[:facebook_session]) &&
>>>>> session[:facebook_session].secured? if  
>>>>> valid_session_key_in_session?
>>>>
>>>> session.secured?
>>>>> !@session_key.nil? && !expired?
>>>>
>>>> valid_session_key_in_session?
>>>>> !session[:facebook_session].blank? &&
>>>>> (params[:fb_sig_session_key].blank? ||
>>>>> session[:facebook_session].session_key ==  
>>>>> facebook_params[:session_key])
>>>>
>>>> The problem for connect is if the following sequence happens:
>>>> - user comes to your site and logs in via facebook,
>>>> - user goes to facebook in another browser tab and logs out
>>>> - user returns to your site
>>>>
>>>> The connect app will have the following state:
>>>> - session[:facebook_session]
>>>> - @session_key && !expired?
>>>> - params[:fb_sig_session_key].blank?
>>>>
>>>> So they're technically still logged in and your app will throw an
>>>> exception when trying to access user info.
>>>>
>>>> One solution for a pure connect app is that the session is  
>>>> invalid if the
>>>> cookies aren't present.  They don't
>>>> need to be verified on each request, but they should be checked for
>>>> existence.
>>>>
>>>> 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.  Can
>>>> someone fill me in?
>>>>
>>>> - kevin
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Aaron Nemoyten <swivelmaster at gmail.com>
>>>>> Date: January 21, 2009 6:23:51 PM EST
>>>>> To: All Things Facebook and Ruby <rfacebook at googlegroups.com>
>>>>> Subject: [rfacebook] Re: How exactly are session cookies  
>>>>> supposed to
>>>>> work? Will  ensure_authenticated use them?
>>>>> Reply-To: rfacebook at googlegroups.com
>>>>>
>>>>>
>>>>> Well, I've got an update yet again!
>>>>>
>>>>> Seems that it's possible that new sessions aren't created when  
>>>>> they
>>>>> should be sometimes because of the order that Facebooker checks  
>>>>> for
>>>>> valid session info.
>>>>>
>>>>> If you check out ensure_authenticated_to_facebook, you'll see  
>>>>> this:
>>>>> def set_facebook_session
>>>>>     returning session_set = session_already_secured? ||
>>>>> secure_with_facebook_params! || secure_with_cookies! ||
>>>>> secure_with_token!
>>>>> (etc.)
>>>>>
>>>>> Grabbing the old session if there is new session info available  
>>>>> from
>>>>> the facebook_params seems to cause some problems, as well as  
>>>>> trying to
>>>>> secure with cookies if there's an auth token available (usually
>>>>> involving my Safari iframe fix - we can pop out of the iframe  
>>>>> with the
>>>>> auth token but no params, and Facebooker will grab the old cookie,
>>>>> thus rendering the iframe fix potentially useless.
>>>>>
>>>>> So my preferred order is params, session, auth token, cookies.
>>>>>
>>>>> Another issue I ran into (which may not be relevant since I  
>>>>> moved the
>>>>> cookie auth method last) is that cookies from invalid sessions  
>>>>> will
>>>>> make Facebooker throw an error when all I'd really want to do is  
>>>>> just
>>>>> ignore them and make a new session, so I rescued  
>>>>> secure_with_cookies!
>>>>> for Facebooker::Session::IncorrectSignature and just returned  
>>>>> false.
>>>>>
>>>>> Not sure if I mentioned this before, but it's also necessary to  
>>>>> modify
>>>>> request_comes_from_facebook? to make sure it doesn't incorrectly
>>>>> return false because it's looking for canvas-specific parameters.
>>>>>
>>>>> This seems to have fixed some problems for now.
>>>>>
>>>>> -Aaron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Jan 19, 12:56 am, PanosJee <pap... at freemail.gr> wrote:
>>>>>>
>>>>>> Aaron your posts are highly appreciated, keep up
>>>>>> We also hope to post a few hints, unfortunately IFrames are badly
>>>>>> supported though they are superior technology compared to the  
>>>>>> limited
>>>>>> plain FBML apps
>>>>>
>>>>> --~--~---------~--~----~------------~-------~--~----~
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "All Things Facebook and Ruby" group.
>>>>> To post to this group, send email to rfacebook at googlegroups.com
>>>>> To unsubscribe from this group, send email to
>>>>> rfacebook+unsubscribe at googlegroups.com
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/rfacebook?hl=en
>>>>> -~----------~----~----~----~------~----~------~--~---
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>

More information about the Facebooker-talk mailing list