web-dev-qa-db-fra.com

GCM 3.0 Actualiser le jeton d'inscription nécessaire?

Avec la dernière mise à jour de GCM (3.0), est-il toujours nécessaire de gérer l'actualisation du jeton d'enregistrement lors de situations telles que le redémarrage? Cet article traite de la fiabilité de GCM et couvre plusieurs conditions dans lesquelles le jeton d’enregistrement peut changer. Ces étapes sont-elles nécessaires dans la dernière version? Au cours de la conférence IO 2015, ils ont parlé comme si le jeton d'enregistrement était bon jusqu'à ce que l'application soit désinstallée de l'appareil.

InstanceID instanceID = InstanceID.getInstance(this);
String token = instanceID.getToken(getString(R.string.gcm_defaultSenderId),
    GoogleCloudMessaging.INSTANCE_ID_SCOPE, null);
androidgoogle-cloud-messaging
19
Patrick

Le jeton d'enregistrement ne doit pas s'actualiser après le redémarrage, mais il existe d'autres situations dans lesquelles il peut être actualisé. Vous devez donc le gérer.

Avec l'API mise à jour, vous devez implémenter InstanceIDListenerService afin de gérer l'actualisation des jetons, comme illustré dans l'exemple d'application google-services # Android # gcm .

    /**
     * Called if InstanceID token is updated. This may occur if the security of
     * the previous token had been compromised. This call is initiated by the
     * InstanceID provider.
     */
    // [START refresh_token]
    @Override
    public void onTokenRefresh() {
        // Fetch updated Instance ID token and notify our app's server of any changes (if applicable).
        Intent intent = new Intent(this, RegistrationIntentService.class);
        startService(intent);
    }

En ce qui concerne les autres situations dans lesquelles l'actualisation du jeton peut avoir lieu. 

Un jeton d'enregistrement existant peut ne plus être valide dans un nombre de scénarios, y compris:
- Si l'application cliente se désenregistre avec GCM.
- Si l'application cliente est automatiquement désinscrite, ce qui peut arriver si l'utilisateur désinstalle l'application. Par exemple, sur iOS, si le fichier APNS Le service de retour d'informations a signalé le jeton APNS comme non valide.
- Si le jeton d'enregistrement expire (par exemple, Google peut décider d'actualiser les jetons d'enregistrement ou le jeton APNS a expiré pour les appareils iOS ).
- Si l'application client est mise à jour mais que la nouvelle version n'est pas configurée pour recevoir des messages. 

Pour tous ces cas, supprimez ce jeton d'enregistrement de l'application serveur et arrêtez de l’utiliser pour envoyer des messages.

Pour protéger l'application cliente et le serveur d'applications contre les activités malveillantes potentielles réutilisation des jetons d’enregistrement, vous devez lancer périodiquement le jeton actualiser à partir du serveur. Lorsque l'actualisation du jeton d'enregistrement GCM est initiée depuis le côté serveur, l'application client doit gérer un fichier Message tokenRefreshed avec le client/serveur d'enregistrement GCM poignée de main
Voir la référence de l'API pour plus d'informations sur l'identité et la procédure d'actualisation de jeton.

18
bitek

EDIT: consultez les documents InstanceID car cela montre comment gérer l'actualisation des jetons. https://developers.google.com/instance-id/ et https://developers.google.com/instance-id/guides/Android-implementation

Ce n'est pas très clair d'un serveur PoV imho.

De https://developers.google.com/cloud-messaging/registration#keeping-the-registration-state-in-sync nous avons 

Pour protéger l'application cliente et le serveur d'applications de la réutilisation malveillante potentielle de jetons d'enregistrement, vous devez régulièrement lancer l'actualisation des jetons à partir du serveur. Lorsque l'actualisation du jeton d'enregistrement GCM est lancée côté serveur, l'application cliente doit gérer un message tokenRefreshed avec la négociation client/serveur d'enregistrement GCM. Voir la référence de l'API pour plus d'informations sur l'identité et la procédure d'actualisation de jeton.

Hmm, il n'y a pas de lien pour la référence de l'API - regardez donc l'API du serveur ici https://developers.google.com/cloud-messaging/server-ref#interpret-downstream nous avons un champ canonical_ids qui est 

Nombre de résultats contenant un jeton d'enregistrement canonique. Voir l'aperçu de l'enregistrement pour plus d'informations sur ce sujet.

et un champ results qui a

Chaîne facultative spécifiant le jeton d'enregistrement canonique de l'application client à laquelle le message a été traité et envoyé. L'expéditeur doit utiliser cette valeur comme jeton d'enregistrement pour les demandes futures. Sinon, les messages pourraient être rejetés.

Côté client, nous avons le nouveau https://developers.google.com/Android/reference/com/google/Android/gms/iid/InstanceIDListenerService.html#onTokenRefresh ()

Appelé lorsque le système détermine que les jetons doivent être actualisés. L'application doit appeler getToken () et envoyer les jetons à tous les serveurs d'applications. Ce n'est pas appelé très souvent, il est nécessaire pour la rotation des clés et pour traiter des cas particuliers. Le système limitera l'événement d'actualisation sur tous les périphériques afin d'éviter de surcharger les serveurs d'applications avec des mises à jour de jetons.

Donc, la façon dont vous lancez l'actualisation des jetons à partir du serveur me dépasse! Mais en réponse à votre question - oui, vous devez toujours gérer le jeton pour actualiser le côté client!

EDIT: lecture intéressante Traitement des modifications de l'ID d'enregistrement dans Google Cloud Messaging sur Android

1
Dori