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

[vincent chu]

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
>