Quelles sont les raisons possibles qui peuvent entraîner l'expiration du jeton (en plus du fait que l'utilisateur désautorise l'application)?
Mon problème, c’est que j’ai une application comptant plusieurs milliers d’utilisateurs. Toute la communication avec l’API fonctionne parfaitement, mais pour certains utilisateurs, l’erreur invalid or expired token
est apparue. Ma première remarque était qu’il s’agissait d’utilisateurs qui ont annulé l’authentification de l’application mais que j’ai contactés. certains d'entre eux et ils n'ont pas révoqué l'accès.
Des idées quelles autres questions peuvent causer cette erreur?
Vérifiez l'intégrité d'un jeton d'accès à tout moment en appelant le compte GET/verify_credentials lors de l'utilisation de ce jeton d'accès.
Son mentionné et par la recherche, j'ai appris à savoir que:
Votre jeton d'accès ne sera pas valide si un utilisateur refuse explicitement votre application de leurs paramètres ou si un administrateur de Twitter suspend votre application. Si votre demande est suspendue, il y aura une note sur votre page d'application en disant qu'il a été suspendu.
Pourquoi mon jeton d'accès Twitter oauth est-il invalide/expiré?
Vérifiez cet article: invalid/jetons d’accès expirés .
Il y a un article dans les groupes Google qui dit:
Vous n'obtenez pas une seconde chance, et c'est par conception. OAuth demandes avoir une signature unique; une fois qu'une demande particulière est soumise, il ne peut pas être soumis à nouveau . S'ils entrent correctement dans la broche, tout va bien, vous obtenez un jeton d'accès . S'ils entrent dans la broche de manière incorrecte, vous obtenez 401 Unauthorized - ce qui est attendu. Mais s’ils essayent alors à nouveau d’entrer la goupille, même la goupille correcte montre comme non autorisé.
Cochez link pour la référence ci-dessus.
Quelques suggestions d'employés de Twitter pour le même problème:
Je suppose qu'il y a deux choses que je suggérerais à ce stade: 1.) Allez à vos paramètres d’application et utilisez l’onglet "Réinitialiser les touches" pour réinitialiser votre clé de consommateur et secret, puis mettez à jour ces valeurs dans l'application et vérifiez que vous voyez toujours le même comportement. 2.) Essayez de passer oauth_callback dans votre appel request_token. Honnêtement, je ne pense pas cela Cela fera une différence, mais je veux essayer d’être aussi rigoureux que possible. ici.
Vérifiez également ceci discussion en disant:
Vous devez utiliser les commandes oauth_token et oauth_token_secret renvoyées par l'appel oauth/access_token au lieu de celui défini dans les paramètres de votre application dans dev.Twitter.com
En plus des commentaires que tout le monde a faits, parfois, l’API Twitter renvoie une erreur «Jeton invalide» lorsque le jeton n’est pas le problème. C'est ce que j'ai remarqué le plus souvent lorsque j'ai construit une chaîne de requête qui ne s'analyse pas correctement. Par exemple, une fois, lorsque j'ai eu cette erreur, je passais à l'adresse screen_name contenant des symboles non encodables en URI. Je l'ai aussi obtenu quand j'ai passé des valeurs vides comme ceci (où le curseur est vide):
https://api.Twitter.com/1/followers.json?cursor=&screen_name=whatevah
Pouvez-vous nous donner les détails des appels qui renvoient cette erreur?
J'avais la même erreur alors j'ai changé (access_token) to (access_token_key)
et cela a fonctionné pour moi.
J'espère que ça va aider quelqu'un.
La réponse de mon Dieu est correcte mais je partagerai ma réponse à une autre question expliquant en quoi cela pourrait être l'horloge de votre ordinateur:
Si votre flux OAuth fonctionnait un jour et échouait le lendemain, vérifiez le clock de votre ordinateur. J'utilisais une boîte Vagrant dont le délai était la veille, ce qui a amené l'API Twitter à retourner {"code": 89, "message": "Jeton non valide ou expiré."}. Cela peut également apparaître comme un horodatage 401 hors limites. Vous pouvez utiliser cette commande pour mettre à jour votre horloge sous Ubuntu:
Sudo ntpdate time.nist.gov
La méthode alternative si ntpdate
n'est pas disponible sur votre système:
Sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
si votre jeton d'accès = 738629462149844993-FcWHjfcucCLGEosyGGQ38qI ****** iC, n'oubliez pas de mentionner le trait d'union (-) suivi de votre USERID.
Tout d'abord, belle question Ran.
Je veux vous demander que vous avez passé par les développeurs de Twitter?
Parfois, le jeton à utiliser devient ambigu, puisque Twitter fournit deux paires de jetons et la bibliothèque. L'une d'entre elles est une clé secrète.
Vous devez sélectionner les jetons qui commencent par votre identifiant Twitter suivi d'un trait d'union.
Maintenant, votre question est que cette erreur se produit avec certains de vos utilisateurs. Voici donc la réponse selon laquelle une application elle-même trouve ambiguë de choisir le jeton.
Bien que je n’aie peut-être pas tout à fait raison, je vous recommande d’essayer cette solution au moins une fois.
Il est possible que ces utilisateurs aient un accès non révoqué. Mais dans mon expérience, un jeton d'accès peut également être expiré après que l'utilisateur (dans les cas de test: moi) a changé son mot de passe.
Lorsque l'utilisateur le fait, vous ne pouvez plus utiliser l'API REST de l'API de flux sur l'étendue de cet utilisateur. S'il vous plaît adapter votre application pour gérer cette situation. Révoquez la session de l'utilisateur. Ainsi, lorsqu'il reviendra dans votre application, il pourra à nouveau être redirigé vers Twitter pour lancer un nouveau processus de jeton d'accès OAuth. Ou envoyez-lui un e-mail pour lui demander de bien vouloir vous reconnecter. Vimeo/Windows/... sont quelques-unes des personnes qui gèrent les jetons arrivés à expiration avec des courriels.
S'amuser!
Avez-vous confirmé que les jetons fonctionnaient en même temps? Dans un système OAuth sur lequel j'ai travaillé, il y avait une erreur dans la façon dont les jetons étaient stockés et récupérés de manière sécurisée, ce qui causait la corruption d'un petit pourcentage d'entre eux. Si vous pouvez confirmer que les jetons ont fonctionné dans le passé, c'est une bonne première étape.
Lorsque vous récupérez les jetons de stockage, sont-ils inchangés? Est-il possible qu'ils soient corrompus avec la façon dont vous les gérez?
Mettez en place une connexion pour garder une trace du moment où les jetons fonctionnent et échouent. Un jeton recommence-t-il à fonctionner après avoir échoué une fois? Si vous n'utilisez pas un jeton pendant 30 jours, est-ce qu'il expire? Avec un journal détaillé, vous pouvez commencer à identifier les jetons arrivés à expiration et rechercher les modèles utilisés pour indiquer la cause de leur expiration.
Assurez-vous d'explorer d'autres possibilités également. Comment les utilisateurs révoquent-ils des jetons sur Twitter? Est-ce facile de faire ça accidentellement? Les utilisateurs dont les jetons ont échoué ont-ils d'autres applications autorisées qui ont également cessé de fonctionner?
Peut-être que cela vous sera utile. J'ai rencontré le même problème.
S'il vous plaît trouver l'extrait de code ci-dessous
$code = $tmhOAuth->user_request(array(
'method' => 'POST',
'url' => $tmhOAuth->url('oauth/access_token', ''),
'params' => array(
'oauth_verifier' => trim($params['oauth_verifier']),
)
));
if ($code == 200) {
$oauth_creds = $tmhOAuth->extract_params($tmhOAuth->response['response']);
// echo '<pre>';print_r($oauth_creds);exit;
$tmhOAuth->reconfigure(array_merge($tmhOAuth->config, array(
'token' => $oauth_creds['oauth_token'],
'secret' => $oauth_creds['oauth_token_secret'],
)));
$code = $tmhOAuth->user_request(array(
'url' => $tmhOAuth->url('1.1/account/verify_credentials')
));
}