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

vincent chu vincentchu at gmail.com
Sat Jan 24 15:17:24 EST 2009 

Kevin ---

Perhaps I am not understanding something correctly, but this is my
basic test setup:

1) I have an existing site that I want to enable with fb_connect.

2) I made a very simple controller called 'fb_connect':

class FbConnectController < ApplicationController

  protect_from_forgery :secret => 'XXXXXXXXXXXXXX'
  before_filter :set_facebook_session
  helper_method :facebook_session

  def index
  end

end

3) The view is very simple (pretty much just a copy of the elevated
rails blog post):

<h1>My Great Application</h1>
<%= fb_connect_javascript_tag %>
<%= init_fb_connect "XFBML"%>
<%= fb_login_button%>

<% if facebook_session %>
  <h2>You are logged in as <%= facebook_session.user.name %></h2>
<% else %>
  <h2>You are not logged in!</h2>
<% end %>

4) All the other stuff in the html header (e.g., <html xmlns:fb ..
etc..) is located in the "views/layouts/application.rhtml" file.


Anyway, this is the behavior that I get:

0) User is initially logged out of facebook.com

1) User clicks on the login button and inputs his credentials. He's
logged in correctly to the rails app (rails view successfully reports
that the user is "logged in as so and so"). Cookies are placed in the
user's browser with a valid session_key, etc..

2) User goes to facebook.com and he's logged in. He then clicks
'logout' on facebook.com

3) User reloads the fb_connect/index view and throws an "Session key
invalid or no longer valid" exception. Cookies stick around.

>From my understanding of the code, this is what seems to be happening:

 - Cookies are placed at step #1. Logging out of facebook.com at step
#2 expires the session_key stored in the cookies. However, logging out
doesn't delete them (should it?).

 - Because the cookies weren't deleted, they hang out until the next
reload. Upon reloading the fb_connect/index view, they're scooped up
and used to parameterize a facebook_session. Or, if the reload has
happened within a short enough period, the facebook_session stored in
the user's session variable is used.

 - In either case, facebooker doesn't explicitly check that the
facebook_session created from cookies or the session is valid. Hence
the next reload of the view will throw an exception.

Is this right?

Thanks for the help,

Vince



On Sat, Jan 24, 2009 at 8:43 AM, kevin lochner <klochner at gmail.com> wrote:
> 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
>>>
>
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
>

More information about the Facebooker-talk mailing list