Migrer de l’ancien HTTP vers HTTP v1

Les applications utilisant l’ancienne API HTTP FCM doivent envisager de migrer vers l’API HTTP v1 en suivant les instructions de ce guide. L’API HTTP v1 présente les avantages suivants par rapport à l’ancienne API :

• Meilleure sécurité grâce aux jetons d’accès L’API HTTP v1 utilise des jetons d’accès de courte durée selon le modèle de sécurité OAuth2. Dans le cas où un jeton d’accès devient public, il ne peut être utilisé à des fins malveillantes que pendant environ une heure avant son expiration. Les jetons d’actualisation ne sont pas transmis aussi souvent que les clés de sécurité utilisées dans l’ancienne API, ils sont donc beaucoup moins susceptibles d’être capturés.
• Personnalisation plus efficace des messages sur toutes les plates-formes Pour le corps du message, l’API HTTP v1 possède des clés communes qui vont à toutes les instances ciblées, ainsi que des clés spécifiques à la plate-forme qui vous permettent de personnaliser le message sur toutes les plates-formes. Cela vous permet de créer des « remplacements » qui envoient des charges utiles légèrement différentes à différentes plates-formes clientes dans un seul message.
• Plus extensible et pérenne pour les nouvelles versions de la plateforme client L’API HTTP v1 prend entièrement en charge les options de messagerie disponibles sur les plateformes Apple, Android et Web. Étant donné que chaque plate-forme a son propre bloc défini dans la charge utile JSON, FCM peut étendre l’API à de nouvelles versions et à de nouvelles plates-formes selon les besoins.

1. Mettre à jour le point de terminaison du serveur

L’URL du point de terminaison pour l’API HTTP v1 diffère de l’ancien pont de terminaison comme suit :

• Il est versionné, avec /v1 dans le chemin.
• Le chemin contient l’ID de projet du projet Firebase pour votre application, au format /projects/myproject-ID/ . Cet ID est disponible dans l’onglet Paramètres généraux du projet de la console Firebase.
• Il spécifie explicitement la spécification de la méthode send comme :send .

Pour mettre à jour le point de terminaison du serveur pour HTTP v1, ajoutez ces éléments au point de terminaison dans l’en-tête de vos demandes d’envoi.

Avant

POST https://fcm.googleapis.com/fcm/send

Après

POST https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send

2. Autorisation de mise à jour des demandes d’envoi

Au lieu de la chaîne de clé de serveur utilisée dans les demandes héritées, les demandes d’envoi HTTP v1 nécessitent un jeton d’accès OAuth 2.0. Si vous utilisez le SDK Admin pour envoyer des messages, la bibliothèque gère le jeton pour vous. Si vous utilisez le protocole brut, obtenez le jeton comme décrit dans cette section et ajoutez-le à l’en-tête sous Authorization: Bearer <valid Oauth 2.0 token> .

Avant

Authorization: key=AIzaSyZ-1u...0GBYzPu7Udno5aA

Après

Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA

Selon les détails de votre environnement de serveur, utilisez une combinaison de ces stratégies pour autoriser les requêtes du serveur aux services Firebase :

• Identifiants par défaut de l’application Google (ADC)
• Un fichier JSON de compte de service
• Un jeton d’accès OAuth 2.0 de courte durée dérivé d’un compte de service

Si votre application s’exécute sur Compute Engine, Google Kubernetes Engine, App Engine ou Cloud Functions (y compris Cloud Functions pour Firebase), utilisez les identifiants par défaut de l’application (ADC). ADC utilise votre compte de service par défaut existant pour obtenir des informations d’identification pour autoriser les demandes, et ADC permet des tests locaux flexibles via la variable d’environnement GOOGLE_APPLICATION_CREDENTIALS . Pour une automatisation complète du flux d’autorisation, utilisez ADC avec les bibliothèques de serveur Admin SDK.

Si votre application s’exécute sur un environnement de serveur autre que Google , vous devrez télécharger un fichier JSON de compte de service à partir de votre projet Firebase. Tant que vous avez accès à un système de fichiers contenant le fichier de clé privée, vous pouvez utiliser la variable d’environnement GOOGLE_APPLICATION_CREDENTIALS pour autoriser les demandes avec ces informations d’identification obtenues manuellement. Si vous ne disposez pas d’un tel accès au fichier, vous devez référencer le fichier du compte de service dans votre code, ce qui doit être fait avec une extrême prudence en raison du risque d’exposer vos informations d’identification.

Fournir des informations d’identification à l’aide d’ADC

Google Application Default Credentials (ADC) vérifie vos identifiants dans l’ordre suivant :

1. ADC vérifie si la variable d’environnement GOOGLE_APPLICATION_CREDENTIALS est définie. Si la variable est définie, ADC utilise le fichier de compte de service vers lequel pointe la variable.
2. Si la variable d’environnement n’est pas définie, ADC utilise le compte de service par défaut fourni par Compute Engine, Google Kubernetes Engine, App Engine et Cloud Functions pour les applications qui s’exécutent sur ces services.
3. Si ADC ne peut pas utiliser l’une des informations d’identification ci-dessus, le système génère une erreur.

L’exemple de code du SDK d’administration suivant illustre cette stratégie. L’exemple ne spécifie pas explicitement les informations d’identification de l’application. Cependant, ADC est capable de trouver implicitement les identifiants tant que la variable d’environnement est définie ou tant que l’application s’exécute sur Compute Engine, Google Kubernetes Engine, App Engine ou Cloud Functions.Node.jsJavaPythonAllerC#

admin.initializeApp({
  credential: admin.credential.applicationDefault(),
});

Fournir les informations d’identification manuellement

Les projets Firebase prennent en charge les comptes de service Google , que vous pouvez utiliser pour appeler les API du serveur Firebase à partir de votre serveur d’applications ou de votre environnement de confiance. Si vous développez du code localement ou déployez votre application sur site, vous pouvez utiliser les informations d’identification obtenues via ce compte de service pour autoriser les requêtes du serveur.

Pour authentifier un compte de service et l’autoriser à accéder aux services Firebase, vous devez générer un fichier de clé privée au format JSON.

Pour générer un fichier de clé privée pour votre compte de service :

1. Dans la console Firebase, ouvrez Paramètres > Comptes de service .
2. Cliquez sur Générer une nouvelle clé privée , puis confirmez en cliquant sur Générer la clé .
3. Stockez en toute sécurité le fichier JSON contenant la clé.

Lors de l’autorisation via un compte de service, vous avez deux choix pour fournir les informations d’identification à votre application. Vous pouvez soit définir la variable d’environnement GOOGLE_APPLICATION_CREDENTIALS , soit transmettre explicitement le chemin d’accès à la clé du compte de service dans le code. La première option est plus sécurisée et est fortement recommandée.

Pour définir la variable d’environnement :

Définissez la variable d’environnement GOOGLE_APPLICATION_CREDENTIALS sur le chemin d’accès au fichier JSON contenant la clé de votre compte de service. Cette variable ne s’applique qu’à votre session shell actuelle, donc si vous ouvrez une nouvelle session, définissez à nouveau la variable.Linux ou macOSles fenêtres

export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"

Une fois que vous avez terminé les étapes ci-dessus, les informations d’identification par défaut de l’application (ADC) peuvent déterminer implicitement vos informations d’identification, ce qui vous permet d’utiliser les informations d’identification du compte de service lors des tests ou de l’exécution dans des environnements autres que Google.

Utiliser les informations d’identification pour créer des jetons d’accès

Utilisez vos identifiants Firebase avec la bibliothèque Google Auth pour votre langue préférée afin de récupérer un jeton d’accès OAuth 2.0 de courte durée :node.jsPythonJava

 function getAccessToken() {
  return new Promise(function(resolve, reject) {
    const key = require('../placeholders/service-account.json');
    const jwtClient = new google.auth.JWT(
      key.client_email,
      null,
      key.private_key,
      SCOPES,
      null
    );
    jwtClient.authorize(function(err, tokens) {
      if (err) {
        reject(err);
        return;
      }
      resolve(tokens.access_token);
    });
  });
}index.js

Dans cet exemple, la bibliothèque cliente de l’API Google authentifie la demande avec un jeton Web JSON ou JWT. Pour plus d’informations, consultez Jetons Web JSON .

Après l’expiration de votre jeton d’accès, la méthode d’actualisation du jeton est appelée automatiquement pour récupérer un jeton d’accès mis à jour.

Pour autoriser l’accès à FCM, demandez la portée https://www.googleapis.com/auth/firebase.messaging .

Pour ajouter le jeton d’accès à un en-tête de requête HTTP :

Ajoutez le jeton comme valeur de l’en-tête Authorization au format Authorization: Bearer <access_token> :node.jsPythonJava

headers: {
  'Authorization': 'Bearer ' + accessToken
}index.js

3. Mettre à jour la charge utile des demandes d’envoi

FCM HTTP v1 introduit un changement significatif dans la structuration de la charge utile du message JSON. Principalement, ces modifications garantissent que les messages sont traités correctement lorsqu’ils sont reçus sur différentes plates-formes clientes ; De plus, les modifications vous offrent une flexibilité supplémentaire pour personnaliser ou « remplacer » les champs de message par plate-forme.

En plus d’inspecter les exemples de cette section, consultez Personnalisation d’un message sur plusieurs plates-formes et consultez la référence de l’API pour vous familiariser avec HTTP v1.

Exemple : message de notification simple

Voici une comparaison d’une charge utile de notification très simple – contenant uniquement les champs title , body et data – démontrant les différences fondamentales entre les charges utiles héritées et HTTP v1.

Avant

{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available."
  },
  "data": {
    "story_id": "story_12345"
  }
}

Après

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    }
  }
}

Exemple : ciblage de plusieurs plates-formes

Pour activer le ciblage multiplateforme, l’ancienne API a effectué des remplacements dans le backend. En revanche, HTTP v1 fournit des blocs de clés spécifiques à la plate-forme qui rendent toutes les différences entre les plates-formes explicites et visibles pour le développeur. Cela vous permet de cibler plusieurs plates-formes toujours avec une seule requête, comme illustré dans l’exemple suivant.

Avant

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// Apple
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

Après

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

Exemple : personnalisation avec des remplacements de plate-forme

En plus de simplifier le ciblage multiplateforme des messages, l’API HTTP v1 offre la flexibilité de personnaliser les messages par plateforme.

Avant

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "Check out the Top Story.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// Apple
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

Après

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY",
        "body": "Check out the Top Story"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

Exemple : ciblage d’appareils spécifiques

Pour cibler des appareils spécifiques avec l’API HTTP v1, fournissez le jeton d’enregistrement actuel de l’appareil dans la clé token au lieu de la clé to .

Avant

  { "notification": {
      "body": "This is an FCM notification message!",
      "time": "FCM Message"
    },
    "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1..."
  }

Après

{
   "message":{
      "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
      "notification":{
        "body":"This is an FCM notification message!",
        "title":"FCM Message"
      }
   }
}

Pour plus d’exemples et d’informations sur l’API FCM HTTP v1, consultez le blog Firebase.