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

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
> -~----------~----~----~----~------~----~------~--~---
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/facebooker-talk/attachments/20090123/7cc8b26a/attachment.html>

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

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

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
>

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

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
>

hey vince -

I''m with you now, see below.   Comments appreciated from anyone
as I think there are tradeoffs to be considered in how we approach this.

> 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?).
>
The cookies will be cleared on the 2nd request after the user logs out
of facebook, which is a little late to avoid throwing an exception if  
you''re
invoking the rest api, but this is going to be a relatively rare  
occurrence,
so I''d rather avoid forcing an extra ping of facebook on every request.
> - 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.
>
We''re not going to save cookie-based session information in the  
session hash
anymore, remove the last line from secure_with_cookies!   
(session[:fb_session] = @session)
> - 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.
I don''t like forcing an extra POST to facebook on every page request  
just to make sure the
user hasn''t logged out of fb elsewhere.   I timed them at between .25  
and .5 seconds a pop.
Also note that we''d be forcing an extra post for all canvas apps even  
though they don''t
have the invalid cookie problem.

If you''re using fb connect only as a secondary login credential,  you  
may never throw an
exception anyway, and the cookies will pick up state within a couple  
of requests (or
the session key can expire based on time before they send another  
request).

we could add a test_facebook_session method that  you can call in
any controllers that use the facebook rest api and were secured with  
cookies, but
I''d prefer the following in facebooker/.../controller.rb:

 >  def self.included(controller)
 >  ...
 >   controller.rescue_from Facebooker::Session::SessionExpired, :with  
=> :session_expired
 >  end

 >  def session_expired
 >      clear_fb_cookies!
 >      clear_facebook_session_information
 >      flash[:error] = "Your facebook session has expired."
 >      redirect_to "/"
 >  end

note that with this approach you will have to explicitly pre-load data  
in the
controller rather than invoking the facebook rest api in the view  
(which is
what you did in your example).

  - kevin


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/facebooker-talk/attachments/20090126/22708354/attachment.html>