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

[kevin lochner]

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
>
>
>