Quand les jetons GCM expirent-ils et quel est L'InstanceID?
Puisque GCM ne cesse d'être mis à jour, la plupart des ressources que j'ai recherchées semblent obsolètes ou peu claires. Fondamentalement, je suis confus quand les jetons et les identifiants expirent. (Pour référence, je travaille avec Android.)
D'après ce que je comprends (et corrigez-moi si je me trompe), mon serveur a une clé API et un ID D'expéditeur. En utilisant L'ID de L'expéditeur, je peux demander à mon client de demander un jeton via L'InstanceID stocké localement sur mon client. Je suis déjà un peu confus ici. L'InstanceID est affecté au moment mon application va en ligne? Ne jamais changer? Qu'en est-il lorsque l'application est mise à niveau ou désinstallée et réinstallée (ou que l'appareil est restauré)? En appelant InstanceID.getInstance vais-je toujours récupérer le même InstanceID, ou finira-t-il par expirer et en donner un nouveau? Y a-t-il une valeur pour stocker la chaîne que vous récupérez en appelant getID()? Les documents semblent indiquer que vous récupérez réellement un nouvel InstanceID lorsque vous appelez getID (), ce qui complique encore plus les choses. (Pour référence, je suis se référant à: https://developers.google.com/instance-id/)
En utilisant InstanceID, mon client peut demander un jeton aux serveurs GCM, qu'il envoie ensuite à mon serveur d'applications. Mon serveur d'application stocke ce jeton et peut l'utiliser pour envoyer des messages aux serveurs GCM, qui envoient ensuite le message à l'appareil. L'appareil utilise L'InstanceID stocké pour recevoir ces messages, je crois. Donc avoir une classe qui étend GcmListenerService me permettra de les recevoir messages avec onMessageReceived? Je n'ai rien à faire de spécial (autre que de le définir dans L'AndroidManifest)? Je n'ai pas besoin de lui dire d'utiliser InstanceID? Il vient comme par magie sait?
Quand ces ID et jetons expirent-ils? Font-ils une date d'expiration? Je stocke le jeton sous forme de chaîne sur le serveur, mais si à un moment donné l'un d'entre eux expire, Comment puis-je savoir qu'ils ont expiré? Je peux toujours générer un nouvel InstanceID et un jeton, cela semble facile, mais les anciens restent-ils actifs? Comment est-ce que j'efface les anciens jetons du serveur? Il semble y avoir un moyen facile de le faire avec APNS du côté iOS des choses, où vous pouvez récupérer une liste de tous les jetons expirés et simplement les effacer de votre base de données.
3 réponses
Je me suis retrouvé à poser la plupart de ces questions moi-même lorsque je mets à jour mon implémentation GCM. Après avoir déconné avec elle quelques jours, voici mon point de vue sur vos questions.
D'après ce que je comprends (et corrigez-moi si je me trompe), mon serveur a une clé API et un ID D'expéditeur. En utilisant L'ID de L'expéditeur, je peux demander à mon client de demander un jeton via L'InstanceID stocké localement sur mon client.
C'est correct.
L'InstanceID est affecté au moment où mon application passe en ligne?
Il semble qu'il soit affecté dès le lancement de votre application, même si l'appareil ne peut pas accéder à Internet.
Est-ce que ça change jamais? Qu'en est-il lorsque l'application est mise à niveau ou désinstallée et réinstallée (ou que l'appareil est restauré)? En appelant InstanceID.getInstance vais-je toujours récupérer le même InstanceID, ou finira-t-il par expirer et en donner un nouveau?
Selon la documentation InstanceID :
L'ID D'Instance est stable mais peut devenir invalide si:
- l'application supprime L'ID D'Instance
- L'appareil est réinitialisé d'usine
- Utilisateur désinstalle l'application
- l'utilisateur efface les données de l'application
Si L'ID D'Instance est devenu invalide, l'application peut appeler getId () pour demander un nouvel ID D'Instance.
J'ai testé la désinstallation de l'application et l'effacement des données, et les résultats indiquent que tout ce qui précède est vrai.
Y a-t-il une valeur à stocker la chaîne que vous récupérez en appelant getID ()?
Il semble que L'API gère le stockage dans le stockage local de votre application pour vous.
En utilisant InstanceID, mon client peut demander un jeton aux serveurs GCM, qu'il envoie ensuite à mon serveur d'applications. Mon serveur d'application stocke ce jeton et peut l'utiliser pour envoyer des messages aux serveurs GCM, qui envoient ensuite le message à l'appareil. Le périphérique utilise L'InstanceID stocké pour recevoir réellement ces messages, je croire. Donc, avoir une classe qui étend GcmListenerService me permettra de recevoir ces messages avec onMessageReceived? Je n'ai rien à faire de spécial (autre que de le définir dans L'AndroidManifest)? Je n'ai pas besoin de lui dire d'utiliser InstanceID? Il vient comme par magie sait?
Autant que je sache, il n'y avait aucune sorte D'InstanceId dans l'implémentation précédente, et il ne semble pas non plus qu'il soit explicitement utilisé dans celui-ci. Si il l'est, il est appelé dans GcmReceiver ou GcmListenerService.
Quand ces ID et jetons expirent-ils? Font-ils une date d'expiration?
J'ai déjà abordé l'expiration de L'ID et nous pouvons en savoir plus sur les jetons expirant dans le guide d'implémentation Android InstanceID :
Le service ID D'Instance lance des rappels périodiquement (par exemple, tous les 6 mois), demandant à votre application d'actualiser ses jetons. Il peut également lancer des rappels quand:
- Il y a des problèmes de sécurité; par exemple, SSL ou problèmes de plate-forme.
- les informations sur L'appareil ne sont plus valides; par exemple, sauvegarde et restauration.
- le service ID D'Instance est autrement affecté.
Le guide dit de sous-classe InstanceIDListenerService et remplacer onTokenRefresh() pour gérer ces scénarios.
Je stocke le jeton sous forme de chaîne sur le serveur, mais si à un moment donné l'un d'entre eux expire, Comment puis-je savoir ils ont expiré?
Le guide pour implémenter GCM sur votre serveur indique que le serveur GCM répondra à votre serveur avec des informations sur le jeton que vous avez utilisé pour essayer d'envoyer la notification push.
Je peux toujours générer un nouvel InstanceID et un jeton, cela semble facile,mais les anciens restent-ils actifs?
Mes tests suggèrent que oui, ils le font.
Comment puis-je effacer les anciens jetons du serveur? Il semble qu'il y soyez un moyen facile de le faire avec APNS sur le côté iOS des choses, où vous pouvez récupérer une liste de tous les jetons expirés et juste les effacer de votre base de données.
Je suis toujours à la recherche et je mettrai à jour si je peux comprendre quelque chose.
@ pumpkinpie65 et @ B. Roth voici ce que j'ai fait pour détecter les jetons invalides dans ma base de données.
Il existe une option "Dry run" dans GCM lors de l'envoi d'une notification à l'utilisateur/Liste d'utilisateurs. Lorsque vous définissez dry-run lors de l'envoi de notifications, il n'alerte pas les clients ou ne leur affiche pas de notifications, mais renvoie une réponse indiquant quels jetons sont valides(200) et lesquels ne le sont pas.
Si vous envoyez une notification à 200 utilisateurs avec l'option dry-run, alors dans le même ordre, vous obtiendrez la réponse de GCM.
Qu'est-ce que L'ID D'Instance?
Id D'Instance fournit un ID unique par instance de vos applications. Vous pouvez implémenter L'ID D'Instance pour les applications Android et iOS ainsi que les applications/extensions Chrome.
En plus de fournir des id uniques pour l'authentification, L'ID D'Instance peut générer des jetons de sécurité à utiliser avec d'autres services.
Caractéristiques Principales
- Générer Des Jetons De Sécurité
- vérifier l'authenticité de l'application
- confirmer que le périphérique de l'application est actif
- identifier et suivre apps
Cycle de vie de L'ID D'Instance
- le service ID D'Instance émet un InstanceID lorsque votre application est en ligne. L'InstanceID est soutenu par une paire de clés publique/privée avec la clé privée stockée sur le périphérique local et la clé publique enregistrée avec le service ID D'Instance.
- votre application peut demander un nouvel InstanceID chaque fois que nécessaire en utilisant la méthode getID (). Votre application peut stocker sur votre serveur si vous en avez un qui prend en charge votre application.
- Votre application peut demandez des jetons au service ID D'Instance si nécessaire en utilisant la méthode getToken (), et comme InstanceID, votre application peut également stocker des jetons sur votre propre serveur. Tous les jetons émis à votre application appartiennent à InstanceID de l'application. Les jetons
- sont uniques et sécurisés, mais votre application ou le service ID D'Instance peut avoir besoin d'actualiser les jetons en cas de problème de sécurité ou lorsqu'un utilisateur désinstalle et réinstalle votre application pendant la restauration de l'appareil. Votre application doit implémenter un écouteur pour répondre à l'actualisation du jeton les demandes à partir de l'ID de l'Instance de service.
Quand L'ID D'Instance devient-il invalide?
- l'application supprime L'ID D'Instance
- L'appareil est réinitialisé d'usine
- Utilisateur désinstalle l'application
- l'utilisateur efface les données de l'application
Si L'ID D'Instance est devenu invalide, l'application peut appeler getId () pour demander un nouvel ID D'Instance. Pour prouver la propriété de L'ID D'Instance et permettre aux serveurs d'accéder aux données ou aux services associés à l'application, appelez getToken (String, Chaîne).
Quand actualiser les jetons?
Le service ID D'Instance lance des rappels périodiquement (par exemple, tous les 6 mois), demandant à votre application d'actualiser ses jetons. Il peut également lancer des rappels lorsque:
Il y a des problèmes de sécurité; par exemple, SSL ou problèmes de plate-forme. Les informations sur l'appareil ne sont plus valides; par exemple, sauvegarde et restauration. Le service ID D'Instance est autrement affecté.
Tout ce que vous devez savoir sur L'ID D'Instance peut être trouvé dans le liens officiels suivants: