views:

31

answers:

1

The following is what Facebook gives as a cookie to a website that uses Facebook connect.

It issues one cookie with the name fbs____<appID>_____, and can be splitted using the & character: (numbers changed... but they are in similar form)

Array
(
    [0] => "access_token=32480239450325|2.39F_lt3098asddASDL__.3600.1287892800-123456789|H9348aKljsakasd
    [1] => base_domain=www.example.com
    [2] => expires=1287892800
    [3] => secret=032480XYZ023489__
    [4] => session_key=2.39F_lt3098asddASDL__.3600.1287892800-123456789
    [5] => sig=8023948acbd43243
    [6] => uid=123456789"
)

The 32480239450325 is the appID.

I thought if we MD5 or SHA1 the access_token's 1st part with the uid with our app's secret key, then we can verify that it equals to the access_token's 2nd part or the last part, and confirm that it is a valid access_key and user.

So why do we need session_key, secret, and sig? In fact, the session_key is part of the access_token, so why repeat it...?

+1  A: 

To support legacy applications that might still be using the old fb_sig parameter

BeRecursive
you mean some page might use the Graph API, and some other pages in the same app may use REST API. (but can't use both old REST Javascript SDK and new Graph Javascript SDK on the same page)
動靜能量
Thats the one - some peopl are extending legacy applications with new graph API code, so both authentication methods are required
BeRecursive

related questions