Pourquoi l'API Graph de Facebook émet un cookie pour "access_token", "secret", "session_key", "sig" ... autant de champs?

Ce qui suit est ce que Facebook donne comme un cookie à un site Web qui utilise Facebook Connect.Pourquoi l'API Graph de Facebook émet un cookie pour "access_token", "secret", "session_key", "sig" ... autant de champs?

Il émet un cookie avec le nom fbs____<appID>_____ et peut être divisé en utilisant le caractère &: (nombre changé ... mais ils sont en forme similaire)

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

Le 32480239450325 est le appID. Je pensais que si nous MD5 ou SHA1 la 1ère partie d'access_token avec l'UID avec la clé secrète de notre application, alors nous pouvons vérifier qu'elle est égale à la 2ème partie ou la dernière partie d'access_token, et confirmer qu'il s'agit d'une clé d'accès valide. utilisateur. Alors pourquoi avons-nous besoin de session_key, secret, et sig? En fait, le session_key fait partie du access_token, alors pourquoi le répéter ...?

Source

2010-10-24 太極者無極而生

Pour soutenir les applications existantes qui pourraient encore utiliser l'ancien paramètre fb_sig

Source

2010-10-24 11:18:14 BeRecursive

vous dire une page peut utiliser l'API graphique, et d'autres pages dans la même application peut utiliser l'API REST. (mais ne peut pas utiliser à la fois l'ancien SDK JavaScript REST et le nouveau SDK Graph Javascript sur la même page) –

C'est la seule qui étend les applications héritées avec un nouveau code API, donc les deux méthodes d'authentification sont requises – BeRecursive

Pourquoi l'API Graph de Facebook émet un cookie pour "access_token", "secret", "session_key", "sig" ... autant de champs?

Répondre

Questions connexes