Autoriser les requêtes d'envoi

Requêtes envoyées à FCM depuis votre serveur d'applications ou votre environnement approuvé doit être autorisé. Notez les différences importantes entre l'ancienne API HTTP obsolète et l'autorisation de l'API HTTP v1 :

• L'API HTTP v1 FCM autorise les requêtes avec un jeton d'accès OAuth 2.0 de courte durée. Pour créer ce jeton, vous pouvez utiliser les identifiants par défaut de l'application Google (dans les environnements de serveur Google) et/ou obtenir manuellement les identifiants requis à partir d'un fichier de clé privée JSON généré pour un compte de service. Si vous utilisez Firebase Admin SDK pour envoyer des messages, la bibliothèque gère le jeton pour vous.
• Les anciens protocoles obsolètes ne peuvent utiliser que des clés API à durée de vie longue obtenues à partir de la console Firebase.

Attention :Veillez toujours à utiliser le bon type d'identifiant. Une clé API ne permet d'autoriser que les requêtes envoyées à l'ancienne API obsolète.

Autoriser les requêtes d'envoi HTTP v1

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

• Identifiants par défaut de l'application Google (ADC)
• Un fichier JSON de compte de service
• 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 for Firebase), utilisez les identifiants par défaut de l'application (ADC). L'ADC utilise votre compte de service par défaut existant pour obtenir des identifiants permettant d'autoriser les requêtes. Il permet également d'effectuer des tests locaux flexibles via la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS. Pour une automatisation optimale flux d'autorisation, utilisez ADC avec les bibliothèques serveur du SDK Admin.

Si votre application s'exécute dans un environnement serveur autre que Google, vous devez 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 requêtes avec ces identifiants obtenus manuellement. Si vous n'avez pas vous devez référencer le fichier du compte de service dans votre code : ce qui doit être fait avec un soin extrême en raison du risque d'exposition de vos identifiants.

Fournir des identifiants à l'aide de l'ADC

Les identifiants par défaut de l'application (ADC) de Google recherchent vos identifiants dans l'ordre suivant :

1. ADC vérifie si la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS est défini. Si elle est définie, l'ADC utilise le fichier de compte de service vers lequel la variable renvoie.

2. Si la variable d'environnement n'est pas définie, ADC utilise le compte de service par défaut que Compute Engine, Google Kubernetes Engine, App Engine, Cloud Functions et Cloud Functions fournissent des applications qui s'exécutent sur ces services.

3. Si l'ADC ne peut utiliser aucune des informations d'identification ci-dessus, le système génère une erreur.

L'exemple de code du SDK Admin suivant illustre cette stratégie. Il n'indique pas explicitement les identifiants de l'application. Toutefois, l'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.js

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

Java

FirebaseOptions options = FirebaseOptions.builder()
    .setCredentials(GoogleCredentials.getApplicationDefault())
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com/")
    .build();

FirebaseApp.initializeApp(options);

Python

default_app = firebase_admin.initialize_app()

Go

app, err := firebase.NewApp(context.Background(), nil)
if err != nil {
	log.Fatalf("error initializing app: %v\n", err)
}
init.go

C#

FirebaseApp.Create(new AppOptions()
{
    Credential = GoogleCredential.GetApplicationDefault(),
});

Fournir des identifiants manuellement

Les projets Firebase sont compatibles avec comptes de service, que vous pouvez utiliser pour appeler Firebase de votre serveur d'applications ou de votre environnement approuvé. Si vous développez du code localement ou déployez votre application sur site, vous pouvez utiliser les identifiants obtenus 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 Generate New Private Key (Générer une nouvelle clé privée), puis confirmez en cliquant sur Generate Key (Générer la clé).

3. Stockez de manière sécurisée le fichier JSON contenant la clé.

Lorsque vous autorisez l'accès via un compte de service, vous avez deux choix pour fournir les identifiants à votre application. Vous pouvez définir la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS ou 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 vivement recommandée.

Pour définir la variable d'environnement :

Définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS pour qu'elle pointe vers le chemin du fichier JSON contenant la clé de votre compte de service. Cette variable ne s'applique qu'à la session de shell actuelle. Par conséquent, si vous ouvrez une nouvelle session, définissez à nouveau la variable.

Linux ou macOS

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

Windows

Avec PowerShell :

$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"

Une fois les étapes ci-dessus effectuées, Identifiants par défaut de l'application (ADC) peut déterminer implicitement vos identifiants, ce qui vous permet d'utiliser le service identifiants de compte de service lors des tests ou des exécutions dans des environnements autres que Google.

Utiliser des identifiants pour générer des jetons d'accès

Sauf si vous utilisez le SDK Admin, qui gère l'autorisation automatiquement, vous devez créer le jeton d'accès et l'ajouter pour envoyer des requêtes.

Utilisez vos identifiants Firebase avec la bibliothèque Google Auth dans la langue de votre choix pour récupérer un jeton d'accès OAuth 2.0 de courte durée :

Node.js

 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 requête avec un jeton Web JSON (JWT). Pour en savoir plus, consultez la section Jetons Web JSON.

Python

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = service_account.Credentials.from_service_account_file(
    'service-account.json', scopes=SCOPES)
  request = google.auth.transport.requests.Request()
  credentials.refresh(request)
  return credentials.token
messaging.py

Java

private static String getAccessToken() throws IOException {
  GoogleCredentials googleCredentials = GoogleCredentials
          .fromStream(new FileInputStream("service-account.json"))
          .createScoped(Arrays.asList(SCOPES));
  googleCredentials.refresh();
  return googleCredentials.getAccessToken().getTokenValue();
}
Messaging.java

Une fois votre jeton d'accès expiré, 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 le champ d'application 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 en tant que valeur de l'en-tête Authorization au format Authorization: Bearer <access_token>:

Node.js

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

Python

headers = {
  'Authorization': 'Bearer ' + _get_access_token(),
  'Content-Type': 'application/json; UTF-8',
}
messaging.py

Java

URL url = new URL(BASE_URL + FCM_SEND_ENDPOINT);
HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
httpURLConnection.setRequestProperty("Authorization", "Bearer " + getServiceAccountAccessToken());
httpURLConnection.setRequestProperty("Content-Type", "application/json; UTF-8");
return httpURLConnection;
FirebaseMessagingSnippets.java

Autoriser les demandes d'envoi du protocole précédent

Attention : L'envoi de messages (y compris les messages en amont) à l'aide des anciennes API XMPP et HTTP FCM a été abandonné le 20 juin 2023 et sera supprimé à partir de juin 2024. Si vous utilisez les anciennes API d'envoi FCM, nous vous recommandons vivement de migrer vers l'API HTTP v1 ou d'envisager d'utiliser le SDK Admin pour créer des requêtes d'envoi.

Avec l'ancien protocole HTTP, chaque requête doit contenir la clé de serveur du le <ph type="x-smartling-placeholder"></ph> Onglet "Cloud Messaging" de la section Paramètres de la console Firebase volet. Pour XMPP, vous devez utiliser la même clé de serveur pour établir une connexion.

Important : La clé de serveur trouvée dans la console ne peut pas autoriser l'envoi de requêtes via l'API HTTP v1. Elle n'est utilisée que pour les anciennes requêtes HTTP et XMPP.

Migrer les anciennes clés de serveur

Depuis mars 2020, FCM ne crée plus d'anciennes clés de serveur. Les anciennes clés de serveur existantes continueront de fonctionner, mais nous vous recommandons de utilisez plutôt la nouvelle version de la clé intitulée Server key (Clé de serveur) la console Firebase.

Si vous souhaitez supprimer une ancienne clé de serveur existante, vous pouvez le faire dans la console Google Cloud.

Attention : Si vous regénérez une clé API dans la console Google Cloud, vous ne pourrez plus l'utiliser pour autoriser les requêtes FCM.

Autoriser les requêtes HTTP

Une demande de message se compose de deux parties: l'en-tête HTTP et le corps HTTP. L'en-tête HTTP doit contenir les en-têtes suivants :

• Authorization: key=YOUR_SERVER_KEY
  Assurez-vous qu'il s'agit bien de la clé server, dont la valeur est disponible dans les Onglet Cloud Messaging du volet Paramètres de la console Firebase. Les clés Android, de la plate-forme Apple et du navigateur sont rejetées par FCM.
• Content-Type: application/json pour JSON ; application/x-www-form-urlencoded;charset=UTF-8 pour le texte brut.
  Si Content-Type est omis, le format est considéré comme du texte brut.

Exemple :

Content-Type:application/json
Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA

{
  "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
  "data" : {
    ...
  },
}

Pour en savoir plus sur la création de demandes d'envoi, consultez Créer des demandes d'envoi. Documentation de référence sur l'ancien protocole HTTP fournit une liste de tous les paramètres que votre message peut contenir.

Vérifier la validité d'une clé de serveur

Si vous recevez des erreurs d'authentification lorsque vous envoyez des messages, vérifiez la validité de votre clé serveur. Par exemple, sous Linux, exécutez la commande suivante:

api_key=YOUR_SERVER_KEY

curl --header "Authorization: key=$api_key" \
     --header Content-Type:"application/json" \
     https://fcm.googleapis.com/fcm/send \
     -d "{\"registration_ids\":[\"ABC\"]}"

Si vous recevez un code d'état HTTP 401, votre clé de serveur n'est pas valide.

Autoriser une connexion XMPP

Attention :Envoyer des messages (y compris des messages en amont) avec le FCM Les anciennes API XMPP et HTTP ont été abandonnées le 20 juin 2023. seront supprimées à partir de juin 2024. Si vous utilisez les anciennes API d'envoi FCM, nous vous recommandons vivement de migrer vers l'API HTTP v1 ou d'envisager d'utiliser le SDK Admin pour créer des requêtes d'envoi.

Avec XMPP, vous pouvez maintenir une connexion bidirectionnelle persistante et asynchrone aux serveurs FCM. Cette connexion peut être utilisée pour envoyer et recevoir des messages entre votre serveur et les appareils connectés à FCM de vos utilisateurs.

Vous pouvez utiliser la plupart des bibliothèques XMPP pour gérer une connexion longue durée à FCM. Le point de terminaison XMPP s'exécute fcm-xmpp.googleapis.com:5235 Lors des tests avec des utilisateurs qui n'utilisent pas l'environnement de production, connectez-vous plutôt fcm-xmpp.googleapis.com:5236 (notez l'autre port).

Les tests réguliers en préproduction (un environnement plus petit où les dernières versions de FCM s'exécutent) sont utiles pour isoler les utilisateurs réels du code de test. Les appareils de test et le code de test qui se connectent à fcm-xmpp.googleapis.com:5236 doivent utiliser un ID d'expéditeur FCM différent pour éviter tout risque d'envoi de messages de test aux utilisateurs de production ou d'envoi de messages en amont à partir du trafic de production via des connexions de test.

La connexion nécessite deux exigences importantes:

• Vous devez établir une connexion TLS (Transport Layer Security). Notez que FCM n'est actuellement pas compatible avec l'extension STARTTLS.
• FCM nécessite un mécanisme d'authentification SASL PLAIN à l'aide de <your_FCM_Sender_Id>@fcm.googleapis.com (ID d'expéditeur FCM) et de la clé du serveur comme mot de passe. Ces valeurs sont disponible dans les Onglet Cloud Messaging du volet Paramètres de la console Firebase.

Si la connexion échoue à un moment donné, vous devez vous reconnecter immédiatement. Il n'est pas nécessaire de revenir en arrière après une déconnexion qui se produit après l'authentification. Pour chaque ID d'expéditeur : FCM autorise 2 500 connexions en parallèle.

Les extraits de code suivants montrent comment effectuer une authentification une autorisation de connexion XMPP avec FCM.

Serveur XMPP

Le serveur XMPP demande une connexion à FCM

<stream:stream to="fcm.googleapis.com"
        version="1.0" xmlns="jabber:client"
        xmlns:stream="http://etherx.jabber.org/streams">

FCM

FCM ouvre la connexion et demande un mécanisme d'authentification, y compris la méthode PLAIN.

<stream:features>
  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
    <mechanism>X-OAUTH2</mechanism>
    <mechanism>X-GOOGLE-TOKEN</mechanism>
    <mechanism>PLAIN</mechanism>
  </mechanisms>
</stream:features>

Serveur XMPP

Le serveur XMPP doit répondre à l'aide de la méthode d'authentification PLAIN, en fournissant la clé de serveur dans l'onglet Cloud Messaging du volet Settings (Paramètres) de la console Firebase.

<auth mechanism="PLAIN"
xmlns="urn:ietf:params:xml:ns:xmpp-sasl">MTI2MjAwMzQ3OTMzQHByb2plY3RzLmdjbS5hb
mFTeUIzcmNaTmtmbnFLZEZiOW1oekNCaVlwT1JEQTJKV1d0dw==</auth>

FCM

<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

Serveur XMPP

<stream:stream to="fcm.googleapis.com"
        version="1.0" xmlns="jabber:client"
        xmlns:stream="http://etherx.jabber.org/streams">

FCM

<stream:features>
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
  <session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>
</stream:features>

Serveur XMPP

<iq type="set">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"></bind>
</iq>

FCM

<iq type="result">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
    <jid>[e-mail]/RESOURCE</jid>
  </bind>
</iq>

Remarque: FCM n'utilise pas la ressource liée lors du routage des messages.

Voir <ph type="x-smartling-placeholder"></ph> Créez des requêtes d'envoi pour en savoir plus sur la création de requêtes d'envoi. Documentation de référence sur l'ancien protocole XMPP fournit une liste de tous les paramètres que votre message peut contenir.