Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

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 ces avantages par rapport à l'ancienne API:

  • Meilleure sécurité via des 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 les plates-formes Pour le corps du message, l'API HTTP v1 a 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 à l'épreuve du temps pour les nouvelles versions de plate-forme client L'API HTTP v1 prend entièrement en charge les options de messagerie disponibles sur iOS, 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.

Mettre à jour le point de terminaison du serveur

L'URL du point de terminaison pour l'API HTTP v1 diffère de l'ancien endpont de ces manières:

  • 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 d' 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

Mettre à jour l'autorisation des demandes d'envoi

À la place 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 en tant que Authorization: Bearer <valid Oauth 2.0 token> .

Avant

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

Après

Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA

En fonction des détails de votre environnement serveur, utilisez une combinaison de ces stratégies pour autoriser les requêtes 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, Kubernetes Engine, App Engine ou Cloud Functions (y compris Cloud Functions pour Firebase), utilisez les informations d'identification par défaut de l'application (ADC). ADC utilise votre compte de service par défaut existant pour obtenir les informations d'identification afin d'autoriser les demandes, et ADC permet des tests locaux flexibles via la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS . Pour une automatisation maximale 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 aux fichiers, 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 informations d'identification 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, Kubernetes Engine, App Engine et Cloud Functions pour les applications qui s'exécutent sur ces services.

  3. Si ADC ne peut utiliser aucune des informations d'identification ci-dessus, le système renvoie une erreur.

L'exemple de code du SDK Admin 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 informations d'identification tant que la variable d'environnement est définie, ou tant que l'application s'exécute sur Compute Engine, 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()

Aller

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

C #

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

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 de 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 demandes 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é de 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 du fichier JSON qui contient votre clé de compte de service. Cette variable s'applique uniquement à votre session shell actuelle, donc 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"

les fenêtres

Avec PowerShell:

$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\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) sont en mesure de déterminer implicitement vos informations d'identification, ce qui vous permet d'utiliser les informations d'identification du compte de service lors du test ou de l'exécution dans des environnements non Google.

Utilisez les informations d'identification pour créer des jetons d'accès

Utilisez vos identifiants Firebase avec la bibliothèque cliente des API Google pour votre langue préférée 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);
    });
  });
}

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 .

Python

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

  :return: Access token.
  """
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      'service-account.json', SCOPES)
  access_token_info = credentials.get_access_token()
  return access_token_info.access_token

Java

private static String getAccessToken() throws IOException {
  GoogleCredential googleCredential = GoogleCredential
      .fromStream(new FileInputStream("service-account.json"))
      .createScoped(Arrays.asList(SCOPES));
  googleCredential.refreshToken();
  return googleCredential.getAccessToken();
}

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 l'étendue 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.js

headers: {
  'Authorization': 'Bearer ' + accessToken
}

Python

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

Java

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

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; en outre, les modifications vous offrent une flexibilité supplémentaire pour personnaliser ou «remplacer» les champs de message par plateforme.

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: cibler plusieurs plates-formes

Pour activer le ciblage sur plusieurs plates-formes, 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 toute différence entre les plates-formes explicite et visible pour le développeur. Cela vous permet de cibler plusieurs plates-formes toujours avec une seule demande, 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"
  }
}
// iOS
{
  "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"
      }
    },
    "aps": {
      "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"
  }
}
// iOS
{
  "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"
        }
      }
    }
  }
}

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