Facebook Graph API: avoir un jeton d’access à l’application, besoin d’un jeton d’access utilisateur sans interaction

Nous avons un site Web de blogs audio qui peut être configuré pour publier des liens vers la chronologie Facebook de l’utilisateur chaque fois qu’il crée un nouveau blog.

Pour ce faire, nous demandons à l’utilisateur d’autoriser notre application lors de la configuration du lien vers leur compte Facebook. Nous obtenons les permissions publish_stream , offline_access et manage_pages (nous en parlerons plus tard).

Tout le code est en C #, mais les principes s’appliquent à n’importe quel langage, car c’est le fonctionnement de l’ API de Facebook qui nous intéresse. Nous utilisons OAuth 2 et l’ API Graph pour réaliser tout cela.

Nous obtenons donc un jeton d’access à l’application à l’ aide de notre identifiant et de notre secret d’application et utilisons ce jeton pour publier sur la timeline de l’utilisateur. Cela fonctionne correctement (car ils ont déjà autorisé notre application à le faire). Nous pouvons également interroger l’API Graph et obtenir leurs préférences , leurs amis et diverses autres données.

Maintenant, voici le problème:

Certains de nos utilisateurs souhaitent publier des mises à jour sur leur propre calendrier ainsi que sur les calendriers des pages qu’ils gèrent. En théorie, c’est simple: vous interrogez l’API pour les pages gérées par l’utilisateur à l’aide de l’URL suivante: https://graph.facebook.com/{useridBuch/accounts?access_token={token}

Le JSON renvoyé par cet appel contient les identifiants de page et les jetons d’access à la page pour ces pages. Vous utilisez ensuite le jeton d’access aux pages pour publier dans les chronologies des pages.

Cependant, lorsque nous essayons d’appeler cette URL avec le jeton d’access à l’ application, nous obtenons une exception OAuthException 102 “Un jeton d’access utilisateur est requirejs pour demander cette ressource”.

Notez que cela diffère de l’exception OAuthException 104 “Un jeton d’access est requirejs pour demander cette ressource” (ce que vous obtiendrez si vous négligez de transmettre un jeton d’access). obtiendrait si le jeton d’access n’était pas valide).

Notre jeton d’access est donc valide, mais pas valide pour cette URL particulière. Il semble donc que nous ayons besoin d’un jeton d’access utilisateur et non d’un jeton d’access à une application pour ce stream particulier (je ne sais plus trop pourquoi cela est le cas, cela semble tout simplement être comme ça).

Toute la documentation Facebook sur ce sujet (et je dois l’avoir lue dans son intégralité jusqu’à présent) mène à un emplacement: http://developers.facebook.com/docs/authentication/server-side/ , également appelé “authentification côté serveur”. Flux “page. Cette page explique comment obtenir le jeton d’access utilisateur insaisissable en redirigeant l’utilisateur vers la boîte de dialog d’authentification et en demandant les permissions appropriées, mais nous devons y parvenir sans interaction de l’utilisateur, qui a déjà donné à notre application toutes les permissions nécessaires . Toute cette publication automatisée a lieu côté serveur dans le post-traitement de l’audio, nous ne pouvons donc pas interagir avec l’utilisateur à ce stade.

Je ne comprends pas. Pourquoi pouvons-nous utiliser le jeton d’access à l’application pour obtenir presque toutes les données que nous voulons de l’utilisateur (enfin, peu importe ce qu’il nous a donné l’autorisation d’obtenir), mais les données / accounts pour lesquelles nous avons besoin d’un jeton d’access (utilisateur) différent?

Quelqu’un peut-il nous expliquer comment nous pouvons obtenir un jeton d’access utilisateur qui nous permettra d’obtenir les données / comptes pour nos utilisateurs sans aucune interaction supplémentaire de l’utilisateur?

Notre jeton d’access est donc valide, mais pas valide pour cette URL particulière. Il semble donc que nous ayons besoin d’un jeton d’access utilisateur et non d’un jeton d’access à une application pour ce stream particulier.

En raison des permissions par type de jeton d’access, vous avez besoin d’un jeton d’access utilisateur valide dans ce cas particulier. Lisez tout sur les jetons d’access et les types . C’est comme ça.

Cette page explique comment obtenir le jeton d’access utilisateur insaisissable en redirigeant l’utilisateur vers la boîte de dialog d’authentification et en demandant les permissions appropriées, mais nous devons y parvenir sans interaction de l’utilisateur, qui a déjà donné à notre application toutes les permissions nécessaires .

Si votre utilisateur a déjà donné ses permissions, pourquoi vous battez-vous alors? Je vous suggère de conserver le jeton d’access utilisateur. A partir de ce point final :

https://www.facebook.com/dialog/oauth?client_id=..&redirect_uri=..&state=..&scope=..&response_type=..&display=.." 

vous récupérez un code, comme ceci:

 YOUR_REDIRECT_URI?code=OAUTH_CODE_GENERATED_BY_FACEBOOK&state=YOUR_STATE_VALUE 

Utilisez ce code pour générer votre jeton d’access utilisateur, comme expliqué ici :

 https://graph.facebook.com/oauth/access_token?client_id=..&redirect_uri=..&client_secret=..&code=.. 

Cela se traduira par une réponse du type:

 access_token=USER_ACCESS_TOKEN&expires=NUMBER_OF_SECONDS_UNTIL_TOKEN_EXPIRES 

Voilà, votre jeton d’access utilisateur. Persistez. Comme vous pouvez le voir, il expire après la valeur indiquée dans la réponse. Si vous utilisez la nouvelle API, elle devrait indiquer 60 jours (ce qui me ramène à ceci: offline_access est obsolète et génère un lien de courte durée – valide pour 2 heures – de jetons). Chaque fois que votre utilisateur se connecte à votre application et utilise l’intégration de Facebook, les jetons sont actualisés à nouveau, 60 jours. Cela signifie que si votre utilisateur ne doit pas se connecter à votre application et l’utiliser pendant 60 jours, celle-ci expirera.

Vous pouvez vérifier si le jeton d’access utilisateur a expiré avec:

 https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN 

Si c’est le cas: renouvelez le jeton d’access utilisateur à l’aide de votre jeton d’access à l’application , il est bien documenté ici . Mais je cite cette partie:

Connexion côté serveur Pour obtenir un nouveau jeton d’access [utilisateur] dans ce cas, vous devez à nouveau passer l’utilisateur par le processus de connexion complet côté serveur. Toutefois, en supposant que l’utilisateur n’ait pas annulé l’autorisation de votre application, lorsque vous le redirectez vers la boîte de dialog OAuth, il ne sera pas invité à réautoriser votre application et sera immédiatement redirigé vers redirect_uri. Cela signifie que le processus de ré-authentification peut sembler relativement transparent pour l’utilisateur.

En bout de ligne: il n’y a pas de jetons d’access utilisateur valables pour toujours, le jeton d’access à l’application l’est cependant. Conservez votre jeton d’access utilisateur et vérifiez s’il est toujours valide avant d’effectuer des appels d’API avec celui-ci. Un utilisateur normal doit utiliser votre application dans un délai de 60 jours et ne pas simplement désautoriser votre application pour le plaisir. Par conséquent, le cas d’utilisation dans lequel l’utilisateur doit autoriser à nouveau est assez rare, mais vous devez vous y attendre.