Facebooker talk - Sep 2008 - SessionExpired when user removes application Authorization

I''ve encountered the following situation during testing:

1.  User is using application
2.  User removes application Authorization
3.  User returns to application and adds it
4.  SessionExpired exception from Facebooker since the  
session[:facebook_session].session_key (and therefore  
facebook_session.session_key) is still using the old key

I am using the standard cookie session store, but Facebooker is doing  
some magic to populate session and I''m not entirely sure where
it''s
coming from.  It can''t be coming from the browser, since the user  
request goes to FB not to my application, so it must be stored by  
Facebooker either IN Facebook''s data store or somewhere on my server  
(opting for the former since I can''t find it anywhere else).

I have created a workaround, but I feel that this must be a scenario  
that other people have tested -- any insight on this?  I am posting my  
small modification/workaround below - basically I am inducing re- 
creation of the session if the stored session_key doesn''t match the  
facebook_params[''session_key''] (but only if  
facebook_params[''session_key''] is actually set).  As
I''m somewhat new
to Ruby, I''d also appreciate any Ruby-fied syntax advice.

If this is something that should be modified in Facebooker, it seems  
like it might be better handled in the session access  
facebook_session_handling.rb so that the new key returns an empty  
session.  I don''t know enough Ruby magic yet to decode the behavior in
that file, but if someone can point me in the right direction I''ll  
test the changes.

/// -> Changes to vendor/plugins/facebooker/lib/facebooker/ails/ 
controller.rb

       # Modified to add !diferent_session_set? call at the beginning  
of the chain
       def session_already_secured?
         !different_session_set? && (@facebook_session =  
session[:facebook_session]) && session[:facebook_session].secured?
       end

       # Added -- only different if both are set and they are set  
differently
       def different_session_set?
         fbs = session[:facebook_session]
         sk = facebook_params[''session_key'']

         fbs && sk && fbs.session_key != sk
       end

///

Cheers,
-Paul

Are you using the latest version of Facebooker? I fixed a similar bug  
in the last couple of weeks.

This has to do with Facebook and the fact that they keep cookies for a  
user even after they de-authorize the application. I''m hoping that the
most recent version might fix this for you.

Mike

On Sep 14, 2008, at 12:03 AM, Paul Covell wrote:
> I''ve encountered the following situation during testing:
>
> 1.  User is using application
> 2.  User removes application Authorization
> 3.  User returns to application and adds it
> 4.  SessionExpired exception from Facebooker since the  
> session[:facebook_session].session_key (and therefore  
> facebook_session.session_key) is still using the old key
>
> I am using the standard cookie session store, but Facebooker is  
> doing some magic to populate session and I''m not entirely sure
where
> it''s coming from.  It can''t be coming from the browser,
since the
> user request goes to FB not to my application, so it must be stored  
> by Facebooker either IN Facebook''s data store or somewhere on my  
> server (opting for the former since I can''t find it anywhere
else).
>
> I have created a workaround, but I feel that this must be a scenario  
> that other people have tested -- any insight on this?  I am posting  
> my small modification/workaround below - basically I am inducing re- 
> creation of the session if the stored session_key doesn''t match
the
> facebook_params[''session_key''] (but only if  
> facebook_params[''session_key''] is actually set).  As
I''m somewhat
> new to Ruby, I''d also appreciate any Ruby-fied syntax advice.
>
> If this is something that should be modified in Facebooker, it seems  
> like it might be better handled in the session access  
> facebook_session_handling.rb so that the new key returns an empty  
> session.  I don''t know enough Ruby magic yet to decode the
behavior
> in that file, but if someone can point me in the right direction  
> I''ll test the changes.
>
> /// -> Changes to vendor/plugins/facebooker/lib/facebooker/ails/ 
> controller.rb
>
>      # Modified to add !diferent_session_set? call at the beginning  
> of the chain
>      def session_already_secured?
>        !different_session_set? && (@facebook_session =  
> session[:facebook_session]) && session[:facebook_session].secured?
>      end
>
>      # Added -- only different if both are set and they are set  
> differently
>      def different_session_set?
>        fbs = session[:facebook_session]
>        sk = facebook_params[''session_key'']
>
>        fbs && sk && fbs.session_key != sk
>      end
>
> ///
>
> Cheers,
> -Paul
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk
--
Mike Mangino
http://www.elevatedrails.com

Hi, I upgraded to the head (ruby script/plugin install -e
http://facebooker.rubyforge.org/svn/trunk/facebooker/)
  and I still see the same failure:

Facebooker::Session::SessionExpired (Session key invalid or no longer  
valid):
     /vendor/plugins/facebooker/lib/facebooker/parser.rb:418:in  
`process''

Reapplying the same patch fixes the problem in this version as well.   
If I understand how it works, the "session" cookie is actually set in
FB and is therefore still valid by Rails standard logic -- so perhaps  
this is the appropriate way to catch this situation?  The stored  
session value has become inconsistent with the outside world and  
should be updated by the [lowest level] code that understands that.

-Paul


On Sep 14, 2008, at 10:25 PM, Mike Mangino wrote:
> Are you using the latest version of Facebooker? I fixed a similar  
> bug in the last couple of weeks.
>
> This has to do with Facebook and the fact that they keep cookies for  
> a user even after they de-authorize the application. I''m hoping
that
> the most recent version might fix this for you.
>
> Mike
>
> On Sep 14, 2008, at 12:03 AM, Paul Covell wrote:
>
>> I''ve encountered the following situation during testing:
>>
>> 1.  User is using application
>> 2.  User removes application Authorization
>> 3.  User returns to application and adds it
>> 4.  SessionExpired exception from Facebooker since the  
>> session[:facebook_session].session_key (and therefore  
>> facebook_session.session_key) is still using the old key
>>
>> I am using the standard cookie session store, but Facebooker is  
>> doing some magic to populate session and I''m not entirely sure
>> where it''s coming from.  It can''t be coming from the
browser, since
>> the user request goes to FB not to my application, so it must be  
>> stored by Facebooker either IN Facebook''s data store or
somewhere
>> on my server (opting for the former since I can''t find it
anywhere
>> else).
>>
>> I have created a workaround, but I feel that this must be a  
>> scenario that other people have tested -- any insight on this?  I  
>> am posting my small modification/workaround below - basically I am  
>> inducing re-creation of the session if the stored session_key  
>> doesn''t match the
facebook_params[''session_key''] (but only if
>> facebook_params[''session_key''] is actually set).  As
I''m somewhat
>> new to Ruby, I''d also appreciate any Ruby-fied syntax advice.
>>
>> If this is something that should be modified in Facebooker, it  
>> seems like it might be better handled in the session access  
>> facebook_session_handling.rb so that the new key returns an empty  
>> session.  I don''t know enough Ruby magic yet to decode the
behavior
>> in that file, but if someone can point me in the right direction  
>> I''ll test the changes.
>>
>> /// -> Changes to vendor/plugins/facebooker/lib/facebooker/ails/ 
>> controller.rb
>>
>>     # Modified to add !diferent_session_set? call at the beginning  
>> of the chain
>>     def session_already_secured?
>>       !different_session_set? && (@facebook_session =  
>> session[:facebook_session]) &&
session[:facebook_session].secured?
>>     end
>>
>>     # Added -- only different if both are set and they are set  
>> differently
>>     def different_session_set?
>>       fbs = session[:facebook_session]
>>       sk = facebook_params[''session_key'']
>>
>>       fbs && sk && fbs.session_key != sk
>>     end
>>
>> ///
>>
>> Cheers,
>> -Paul
>> _______________________________________________
>> Facebooker-talk mailing list
>> Facebooker-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/facebooker-talk
>
> --
> Mike Mangino
> http://www.elevatedrails.com
>
>
>

Iu see you get code from svn but Facebooker code has been moved to github:

Facebooker can be installed as a Rails plugin by:

  script/plugin install git://github.com/mmangino/facebooker.git

There''s more information on Facebooker''s homepage on
rubyforge.

Zhao

On Sun, Sep 14, 2008 at 8:42 AM, Paul Covell <paul.covell at gmail.com>
wrote:
> Hi, I upgraded to the head (ruby script/plugin install -e
> http://facebooker.rubyforge.org/svn/trunk/facebooker/) and I still see the
> same failure:
>
> Facebooker::Session::SessionExpired (Session key invalid or no longer
> valid):
>    /vendor/plugins/facebooker/lib/facebooker/parser.rb:418:in
`process''
>
> Reapplying the same patch fixes the problem in this version as well.  If I
> understand how it works, the "session" cookie is actually set in
FB and is
> therefore still valid by Rails standard logic -- so perhaps this is the
> appropriate way to catch this situation?  The stored session value has
> become inconsistent with the outside world and should be updated by the
> [lowest level] code that understands that.
>
> -Paul
>
>
> On Sep 14, 2008, at 10:25 PM, Mike Mangino wrote:
>
>> Are you using the latest version of Facebooker? I fixed a similar bug
in
>> the last couple of weeks.
>>
>> This has to do with Facebook and the fact that they keep cookies for a
>> user even after they de-authorize the application. I''m hoping
that the most
>> recent version might fix this for you.
>>
>> Mike
>>
>> On Sep 14, 2008, at 12:03 AM, Paul Covell wrote:
>>
>>> I''ve encountered the following situation during testing:
>>>
>>> 1.  User is using application
>>> 2.  User removes application Authorization
>>> 3.  User returns to application and adds it
>>> 4.  SessionExpired exception from Facebooker since the
>>> session[:facebook_session].session_key (and therefore
>>> facebook_session.session_key) is still using the old key
>>>
>>> I am using the standard cookie session store, but Facebooker is
doing
>>> some magic to populate session and I''m not entirely sure
where it''s coming
>>> from.  It can''t be coming from the browser, since the user
request goes to
>>> FB not to my application, so it must be stored by Facebooker either
IN
>>> Facebook''s data store or somewhere on my server (opting
for the former since
>>> I can''t find it anywhere else).
>>>
>>> I have created a workaround, but I feel that this must be a
scenario that
>>> other people have tested -- any insight on this?  I am posting my
small
>>> modification/workaround below - basically I am inducing re-creation
of the
>>> session if the stored session_key doesn''t match the
>>> facebook_params[''session_key''] (but only if
facebook_params[''session_key'']
>>> is actually set).  As I''m somewhat new to Ruby,
I''d also appreciate any
>>> Ruby-fied syntax advice.
>>>
>>> If this is something that should be modified in Facebooker, it
seems like
>>> it might be better handled in the session access
>>> facebook_session_handling.rb so that the new key returns an empty
session.
>>>  I don''t know enough Ruby magic yet to decode the behavior
in that file, but
>>> if someone can point me in the right direction I''ll test
the changes.
>>>
>>> /// -> Changes to
>>> vendor/plugins/facebooker/lib/facebooker/ails/controller.rb
>>>
>>>    # Modified to add !diferent_session_set? call at the beginning
of the
>>> chain
>>>    def session_already_secured?
>>>      !different_session_set? && (@facebook_session
>>> session[:facebook_session]) &&
session[:facebook_session].secured?
>>>    end
>>>
>>>    # Added -- only different if both are set and they are set
differently
>>>    def different_session_set?
>>>      fbs = session[:facebook_session]
>>>      sk = facebook_params[''session_key'']
>>>
>>>      fbs && sk && fbs.session_key != sk
>>>    end
>>>
>>> ///
>>>
>>> Cheers,
>>> -Paul
>>> _______________________________________________
>>> 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
>


-- 
Zhao

Paul,
The way I handle this is to set up my Post-Remove URL and Post-Add  
Urls in your application settings.
Then you need to mark the user as being removed or actually remove  
him, when they hit the post-remove url.
And then you will treat him like a new user when he comes back and re- 
hits the Post-add url.

Not that it''s not a good idea to do what you''re doing,
that''s a fine
way to handle the problem also, IMO.

Hope that helps,

BJ Clark


On Sep 13, 2008, at 10:03 PM, Paul Covell wrote:
> I''ve encountered the following situation during testing:
>
> 1.  User is using application
> 2.  User removes application Authorization
> 3.  User returns to application and adds it
> 4.  SessionExpired exception from Facebooker since the  
> session[:facebook_session].session_key (and therefore  
> facebook_session.session_key) is still using the old key
>
> I am using the standard cookie session store, but Facebooker is  
> doing some magic to populate session and I''m not entirely sure
where
> it''s coming from.  It can''t be coming from the browser,
since the
> user request goes to FB not to my application, so it must be stored  
> by Facebooker either IN Facebook''s data store or somewhere on my  
> server (opting for the former since I can''t find it anywhere
else).
>
> I have created a workaround, but I feel that this must be a scenario  
> that other people have tested -- any insight on this?  I am posting  
> my small modification/workaround below - basically I am inducing re- 
> creation of the session if the stored session_key doesn''t match
the
> facebook_params[''session_key''] (but only if  
> facebook_params[''session_key''] is actually set).  As
I''m somewhat
> new to Ruby, I''d also appreciate any Ruby-fied syntax advice.
>
> If this is something that should be modified in Facebooker, it seems  
> like it might be better handled in the session access  
> facebook_session_handling.rb so that the new key returns an empty  
> session.  I don''t know enough Ruby magic yet to decode the
behavior
> in that file, but if someone can point me in the right direction  
> I''ll test the changes.
>
> /// -> Changes to vendor/plugins/facebooker/lib/facebooker/ails/ 
> controller.rb
>
>      # Modified to add !diferent_session_set? call at the beginning  
> of the chain
>      def session_already_secured?
>        !different_session_set? && (@facebook_session =  
> session[:facebook_session]) && session[:facebook_session].secured?
>      end
>
>      # Added -- only different if both are set and they are set  
> differently
>      def different_session_set?
>        fbs = session[:facebook_session]
>        sk = facebook_params[''session_key'']
>
>        fbs && sk && fbs.session_key != sk
>      end
>
> ///
>
> Cheers,
> -Paul
> _______________________________________________
> Facebooker-talk mailing list
> Facebooker-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facebooker-talk

Good, thanks.  This does fix the problem.

-Paul

On Sep 15, 2008, at 1:28 AM, Zhao Lu wrote:
> Iu see you get code from svn but Facebooker code has been moved to  
> github:
>
> Facebooker can be installed as a Rails plugin by:
>
>  script/plugin install git://github.com/mmangino/facebooker.git
>
> There''s more information on Facebooker''s homepage on
rubyforge.
>
> Zhao
>
> On Sun, Sep 14, 2008 at 8:42 AM, Paul Covell <paul.covell at
gmail.com>
> wrote:
>> Hi, I upgraded to the head (ruby script/plugin install -e
>> http://facebooker.rubyforge.org/svn/trunk/facebooker/) and I still  
>> see the
>> same failure:
>>
>> Facebooker::Session::SessionExpired (Session key invalid or no longer
>> valid):
>>   /vendor/plugins/facebooker/lib/facebooker/parser.rb:418:in  
>> `process''
>>
>> Reapplying the same patch fixes the problem in this version as  
>> well.  If I
>> understand how it works, the "session" cookie is actually set
in FB
>> and is
>> therefore still valid by Rails standard logic -- so perhaps this is  
>> the
>> appropriate way to catch this situation?  The stored session value  
>> has
>> become inconsistent with the outside world and should be updated by  
>> the
>> [lowest level] code that understands that.
>>
>> -Paul
>>
>>
>> On Sep 14, 2008, at 10:25 PM, Mike Mangino wrote:
>>
>>> Are you using the latest version of Facebooker? I fixed a similar  
>>> bug in
>>> the last couple of weeks.
>>>
>>> This has to do with Facebook and the fact that they keep cookies  
>>> for a
>>> user even after they de-authorize the application. I''m
hoping that
>>> the most
>>> recent version might fix this for you.
>>>
>>> Mike
>>>
>>> On Sep 14, 2008, at 12:03 AM, Paul Covell wrote:
>>>
>>>> I''ve encountered the following situation during
testing:
>>>>
>>>> 1.  User is using application
>>>> 2.  User removes application Authorization
>>>> 3.  User returns to application and adds it
>>>> 4.  SessionExpired exception from Facebooker since the
>>>> session[:facebook_session].session_key (and therefore
>>>> facebook_session.session_key) is still using the old key
>>>>
>>>> I am using the standard cookie session store, but Facebooker is
>>>> doing
>>>> some magic to populate session and I''m not entirely
sure where
>>>> it''s coming
>>>> from.  It can''t be coming from the browser, since the
user
>>>> request goes to
>>>> FB not to my application, so it must be stored by Facebooker  
>>>> either IN
>>>> Facebook''s data store or somewhere on my server
(opting for the
>>>> former since
>>>> I can''t find it anywhere else).
>>>>
>>>> I have created a workaround, but I feel that this must be a  
>>>> scenario that
>>>> other people have tested -- any insight on this?  I am posting
my
>>>> small
>>>> modification/workaround below - basically I am inducing re- 
>>>> creation of the
>>>> session if the stored session_key doesn''t match the
>>>> facebook_params[''session_key''] (but only if  
>>>> facebook_params[''session_key'']
>>>> is actually set).  As I''m somewhat new to Ruby,
I''d also
>>>> appreciate any
>>>> Ruby-fied syntax advice.
>>>>
>>>> If this is something that should be modified in Facebooker, it
>>>> seems like
>>>> it might be better handled in the session access
>>>> facebook_session_handling.rb so that the new key returns an
empty
>>>> session.
>>>> I don''t know enough Ruby magic yet to decode the
behavior in that
>>>> file, but
>>>> if someone can point me in the right direction I''ll
test the
>>>> changes.
>>>>
>>>> /// -> Changes to
>>>> vendor/plugins/facebooker/lib/facebooker/ails/controller.rb
>>>>
>>>>   # Modified to add !diferent_session_set? call at the
beginning
>>>> of the
>>>> chain
>>>>   def session_already_secured?
>>>>     !different_session_set? && (@facebook_session
>>>> session[:facebook_session]) &&
session[:facebook_session].secured?
>>>>   end
>>>>
>>>>   # Added -- only different if both are set and they are set  
>>>> differently
>>>>   def different_session_set?
>>>>     fbs = session[:facebook_session]
>>>>     sk = facebook_params[''session_key'']
>>>>
>>>>     fbs && sk && fbs.session_key != sk
>>>>   end
>>>>
>>>> ///
>>>>
>>>> Cheers,
>>>> -Paul
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> -- 
> Zhao