Firebase Cloud Messaging (FCM) offre une large gamme d'options et de fonctionnalités de messagerie. Les informations contenues dans cette page sont destinées à vous aider à comprendre les différents types de messages FCM et ce que vous pouvez en faire.
Types de messages
Avec FCM, vous pouvez envoyer deux types de messages aux clients :
- Messages de notification, parfois considérés comme des "messages d'affichage". Ceux-ci sont gérés automatiquement par le SDK FCM.
- Messages de données, qui sont gérés par l'application cliente.
Les messages de notification contiennent un ensemble prédéfini de clés visibles par l'utilisateur. Les messages de données, en revanche, ne contiennent que vos paires clé-valeur personnalisées définies par l'utilisateur. Les messages de notification peuvent contenir une charge utile de données facultative. La charge utile maximale pour les deux types de messages est de 4 000 octets, sauf lors de l'envoi de messages depuis la console Firebase, qui impose une limite de 1 024 caractères.
| Scénario d'utilisation | Comment envoyer | |
|---|---|---|
| Message de notification | FCM SDK affiche le message aux appareils des utilisateurs finaux au nom de l'application cliente lorsqu'elle s'exécute en arrière-plan. Sinon, si l'application s'exécute au premier plan lorsque la notification est reçue, le code de l'application détermine le comportement. Les messages de notification ont un ensemble prédéfini de clés visibles par l'utilisateur et une charge utile de données facultative de paires clé-valeur personnalisées. |
|
| Message de données | L'application client est responsable du traitement des messages de données. Les messages de données n'ont que des paires clé-valeur personnalisées sans noms de clé réservés (voir ci-dessous). | Dans un environnement de confiance tel que Cloud Functions ou votre serveur d'applications, utilisez le SDK Admin ou les protocoles de serveur FCM : définissez uniquement la clé data . |
Utilisez les messages de notification lorsque vous souhaitez que le SDK FCM gère l'affichage automatique d'une notification lorsque votre application s'exécute en arrière-plan. Utilisez les messages de données lorsque vous souhaitez traiter les messages avec votre propre code d'application client.
FCM peut envoyer un message de notification comprenant une charge utile de données facultative. Dans de tels cas, FCM gère l'affichage de la charge utile de notification et l'application cliente gère la charge utile de données.
Notifications
Pour les tests ou pour le marketing et le réengagement des utilisateurs, vous pouvez envoyer des messages de notification à l'aide de la console Firebase . La console Firebase fournit des tests A/B basés sur l'analyse pour vous aider à affiner et à améliorer les messages marketing.
Pour envoyer par programmation des messages de notification à l'aide du SDK Admin ou des protocoles FCM, définissez la clé notification avec l'ensemble prédéfini nécessaire d'options de valeur-clé pour la partie visible par l'utilisateur du message de notification. Par exemple, voici un message de notification au format JSON dans une application de messagerie instantanée. L'utilisateur peut s'attendre à voir un message avec le titre "Portugal vs. Danemark" et le texte "super match !" sur l'appareil :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}Les messages de notification sont envoyés dans la barre de notification lorsque l'application est en arrière-plan. Pour les applications au premier plan, les messages sont gérés par une fonction de rappel.
Consultez la documentation de référence pour la liste complète des clés prédéfinies disponibles pour la création de messages de notification :
- Objet de notification du protocole HTTP v1
- Charge utile de notification du protocole HTTP hérité
- Charge utile de notification du protocole XMPP
Messages de données
Définissez la clé appropriée avec vos paires clé-valeur personnalisées pour envoyer une charge utile de données à l'application cliente.
Par exemple, voici un message au format JSON dans la même application de messagerie instantanée que ci-dessus, où les informations sont encapsulées dans la clé data commune et l'application cliente est censée interpréter le contenu :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
} L'exemple ci-dessus montre l'utilisation du champ data de niveau supérieur ou commun, qui est interprété par les clients sur toutes les plates-formes qui reçoivent le message. Sur chaque plate-forme, l'application cliente reçoit la charge utile de données dans une fonction de rappel.
Chiffrement des messages de données
La couche de transport Android (voir architecture FCM ) utilise un chiffrement point à point. Selon vos besoins, vous pouvez décider d'ajouter un chiffrement de bout en bout aux messages de données. FCM ne fournit pas de solution de bout en bout. Cependant, il existe des solutions externes disponibles telles que Capillary ou DTLS .
Messages de notification avec données utiles facultatives
Par programmation ou via la console Firebase, vous pouvez envoyer des messages de notification contenant une charge utile facultative de paires clé-valeur personnalisées. Dans l' éditeur de notifications , utilisez les champs de données personnalisés dans les options avancées .
Le comportement de l'application lors de la réception de messages incluant à la fois des charges utiles de notification et de données dépend de si l'application est en arrière-plan ou au premier plan, essentiellement, si elle est active ou non au moment de la réception.
- Lorsqu'elles sont en arrière-plan , les applications reçoivent la charge utile de notification dans la barre de notification et ne gèrent la charge utile de données que lorsque l'utilisateur appuie sur la notification.
- Lorsqu'elle est au premier plan , votre application reçoit un objet de message avec les deux charges utiles disponibles.
Voici un message au format JSON contenant à la fois la clé notification et la clé data :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}Personnaliser un message sur toutes les plateformes
Le SDK Firebase Admin et le protocole HTTP FCM v1 permettent tous deux à vos demandes de message de définir tous les champs disponibles dans l'objet message . Ceci comprend:
- un ensemble commun de champs à interpréter par toutes les instances d'application qui reçoivent le message.
- des ensembles de champs spécifiques à la plate-forme, tels que
AndroidConfigetWebpushConfig, interprétés uniquement par les instances d'application exécutées sur la plate-forme spécifiée.
Les blocs spécifiques à la plate-forme vous permettent de personnaliser les messages pour différentes plates-formes afin de vous assurer qu'ils sont correctement traités lors de leur réception. Le backend FCM prendra en compte tous les paramètres spécifiés et personnalisera le message pour chaque plate-forme.
Quand utiliser les champs communs
Utilisez des champs communs lorsque vous :
- Ciblage des instances d'application sur toutes les plates-formes : Apple, Android et Web
- Envoi de messages aux sujets
Toutes les instances d'application, quelle que soit la plate-forme, peuvent interpréter les champs communs suivants :
Quand utiliser des champs spécifiques à la plate-forme
Utilisez des champs spécifiques à la plate-forme lorsque vous souhaitez :
- Envoyer les champs uniquement à des plates-formes particulières
- Envoyer des champs spécifiques à la plateforme en plus des champs communs
Chaque fois que vous souhaitez envoyer des valeurs uniquement à des plates-formes particulières, n'utilisez pas de champs communs ; utiliser des champs spécifiques à la plate-forme. Par exemple, pour envoyer une notification uniquement aux plates-formes Apple et au Web, mais pas à Android, vous devez utiliser deux ensembles de champs distincts, un pour Apple et un pour le Web.
Lorsque vous envoyez des messages avec des options de livraison spécifiques , utilisez des champs spécifiques à la plate-forme pour les définir. Vous pouvez spécifier différentes valeurs par plate-forme si vous le souhaitez. Cependant, même lorsque vous souhaitez définir essentiellement la même valeur sur toutes les plates-formes, vous devez utiliser des champs spécifiques à la plate-forme. En effet, chaque plate-forme peut interpréter la valeur légèrement différemment. Par exemple, la durée de vie est définie sur Android comme un délai d'expiration en secondes, tandis que sur Apple, elle est définie comme une date d'expiration .
Exemple : message de notification avec options de livraison spécifiques à la plate-forme
La demande d'envoi v1 suivante envoie un titre et un contenu de notification communs à toutes les plates-formes, mais envoie également des remplacements spécifiques à la plate-forme. Plus précisément, la demande :
- définit une longue durée de vie pour les plates-formes Android et Web, tout en définissant la priorité des messages APN (plates-formes Apple) sur un paramètre faible
- définit les clés appropriées pour définir le résultat d'un appui de l'utilisateur sur la notification sur Android et Apple —
click_actionetcategory, respectivement.
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Match update",
"body":"Arsenal goal in added time, score is now 3-0"
},
"android":{
"ttl":"86400s",
"notification"{
"click_action":"OPEN_ACTIVITY_1"
}
},
"apns": {
"headers": {
"apns-priority": "5",
},
"payload": {
"aps": {
"category": "NEW_MESSAGE_CATEGORY"
}
}
},
"webpush":{
"headers":{
"TTL":"86400"
}
}
}
}Consultez la documentation de référence HTTP v1 pour plus de détails sur les clés disponibles dans les blocs spécifiques à la plate-forme dans le corps du message. Pour plus d'informations sur la création de demandes d'envoi contenant le corps du message, consultez Créer des demandes d'envoi .
Options de livraison
FCM fournit un ensemble spécifique d'options de livraison pour les messages envoyés aux appareils Android et permet des options similaires sur les plates-formes Apple et le Web. Par exemple, le comportement de message "réductible" est pris en charge sur Android via collapse_key de FCM, sur Apple via apns-collapse-id et sur JavaScript/Web via Topic . Pour plus de détails, reportez-vous aux descriptions de cette section et à la documentation de référence associée.
Messages non pliables et pliables
Un message non réductible indique que chaque message individuel est remis à l'appareil. Un message non réductible fournit un contenu utile, par opposition à un message réductible tel qu'un "ping" sans contenu vers l'application mobile pour contacter le serveur afin de récupérer des données.
Certains cas d'utilisation typiques des messages non réductibles sont les messages de chat ou les messages critiques. Par exemple, dans une application de messagerie instantanée, vous voudriez livrer chaque message, car chaque message a un contenu différent.
Pour Android, il existe une limite de 100 messages pouvant être stockés sans s'effondrer. Si la limite est atteinte, tous les messages stockés sont supprimés. Lorsque l'appareil est de nouveau en ligne, il reçoit un message spécial indiquant que la limite a été atteinte. L'application peut alors gérer la situation correctement, généralement en demandant une synchronisation complète au serveur d'applications.
Un message réductible est un message qui peut être remplacé par un nouveau message s'il n'a pas encore été remis à l'appareil.
Les cas d'utilisation courants des messages réductibles sont les messages utilisés pour dire à une application mobile de synchroniser les données du serveur. Un exemple serait une application sportive qui met à jour les utilisateurs avec le dernier score. Seul le message le plus récent est pertinent.
Pour marquer un message comme réductible sur Android, incluez le paramètre collapse_key dans la charge utile du message. Par défaut, la clé de repli correspond au nom du package d'application enregistré dans la console Firebase. Le serveur FCM peut stocker simultanément quatre messages réductibles différents par appareil, chacun avec une clé de réduction différente. Si vous dépassez ce nombre, FCM ne conserve que quatre clés de repli, sans aucune garantie quant à celles qui sont conservées.
Les messages de sujet sans charge utile sont réductibles par défaut. Les messages de notification sont toujours réductibles et ignoreront le paramètre collapse_key .
Lequel dois-je utiliser ?
Les messages réductibles sont un meilleur choix du point de vue des performances, à condition que votre application n'ait pas besoin d'utiliser des messages non réductibles. Toutefois, si vous utilisez des messages réductibles, n'oubliez pas que FCM n'autorise qu'un maximum de quatre clés de réduction différentes à utiliser par FCM par jeton d'enregistrement à un moment donné. Vous ne devez pas dépasser ce nombre, sinon cela pourrait entraîner des conséquences imprévisibles.
| Scénario d'utilisation | Comment envoyer | |
|---|---|---|
| Non pliable | Chaque message est important pour l'application cliente et doit être livré. | À l'exception des messages de notification, tous les messages ne sont pas réductibles par défaut. |
| Pliant | Lorsqu'un message plus récent rend un ancien message connexe non pertinent pour l'application cliente, FCM remplace l'ancien message. Par exemple : messages utilisés pour lancer une synchronisation de données à partir du serveur ou messages de notification obsolètes. | Définissez le paramètre approprié dans votre demande de message :
|
Définir la priorité d'un message
Vous disposez de deux options pour attribuer une priorité de remise aux messages en aval : priorité normale et priorité élevée. Bien que le comportement diffère légèrement d'une plate-forme à l'autre, la livraison des messages de priorité normale et élevée fonctionne comme ceci :
Priorité normale. Les messages prioritaires normaux sont livrés immédiatement lorsque l'application est au premier plan. Pour les applications en arrière-plan, la livraison peut être retardée. Pour les messages moins urgents, tels que les notifications de nouveaux e-mails, la synchronisation de votre interface utilisateur ou la synchronisation des données d'application en arrière-plan, choisissez la priorité de livraison normale.
Haute priorité. FCM tente de transmettre immédiatement les messages de haute priorité même si l'appareil est en mode Doze. Les messages de haute priorité sont destinés au contenu sensible au temps et visible par l'utilisateur.
Voici un exemple de message prioritaire normal envoyé via le protocole FCM HTTP v1 pour informer un abonné au magazine qu'un nouveau contenu est disponible au téléchargement :
{
"message":{
"topic":"subscriber-updates",
"notification":{
"body" : "This week's edition is now available.",
"title" : "NewsMagazine.com",
},
"data" : {
"volume" : "3.21.15",
"contents" : "http://www.news-magazine.com/world-week/21659772"
},
"android":{
"priority":"normal"
},
"apns":{
"headers":{
"apns-priority":"5"
}
},
"webpush": {
"headers": {
"Urgency": "high"
}
}
}
}
Pour plus de détails spécifiques à la plate-forme sur la définition de la priorité des messages :
Définir la durée de vie d'un message
FCM délivre généralement les messages immédiatement après leur envoi. Cependant, cela n'est pas toujours possible. Par exemple, si la plate-forme est Android, l'appareil peut être éteint, hors ligne ou autrement indisponible. Ou FCM peut retarder intentionnellement les messages pour empêcher une application de consommer des ressources excessives et d'affecter négativement la durée de vie de la batterie.
Lorsque cela se produit, FCM stocke le message et le transmet dès que possible. Bien que cela convienne dans la plupart des cas, il existe certaines applications pour lesquelles un message en retard pourrait tout aussi bien ne jamais être livré. Par exemple, si le message est un appel entrant ou une notification de chat vidéo, il n'est significatif que pendant une courte période avant la fin de l'appel. Ou si le message est une invitation à un événement, il est inutile s'il est reçu après la fin de l'événement.
Sur Android et Web/JavaScript, vous pouvez spécifier la durée de vie maximale d'un message. La valeur doit être une durée comprise entre 0 et 2 419 200 secondes (28 jours) et elle correspond à la durée maximale pendant laquelle FCM stocke et tente de livrer le message. Les demandes qui ne contiennent pas ce champ utilisent par défaut la période maximale de quatre semaines.
Voici quelques utilisations possibles de cette fonctionnalité :
- Appels entrants de chat vidéo
- Événements d'invitation expirant
- Événements du calendrier
Un autre avantage de la spécification de la durée de vie d'un message est que FCM ne limite jamais les messages avec une valeur de durée de vie de 0 seconde. En d'autres termes, FCM garantit le meilleur effort pour les messages qui doivent être livrés « maintenant ou jamais ». Gardez à l'esprit qu'une valeur time_to_live de 0 signifie que les messages qui ne peuvent pas être livrés immédiatement sont ignorés. Cependant, étant donné que ces messages ne sont jamais stockés, cela offre la meilleure latence pour l'envoi de messages de notification.
Voici un exemple de requête incluant la durée de vie :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
"apns":{
"headers":{
"apns-expiration":"1604750400"
}
},
"android":{
"ttl":"4500s"
},
"webpush":{
"headers":{
"TTL":"4500"
}
}
}
}Durée de vie d'un message
Lorsqu'un serveur d'applications publie un message sur FCM et reçoit un ID de message en retour, cela ne signifie pas que le message a déjà été remis à l'appareil. Cela signifie plutôt qu'il a été accepté pour livraison. Ce qu'il advient du message après son acceptation dépend de nombreux facteurs.
Dans le meilleur des cas, si l'appareil est connecté à FCM, que l'écran est allumé et qu'il n'y a aucune restriction de limitation, le message est envoyé immédiatement.
Si l'appareil est connecté mais en mode Doze, un message de faible priorité est stocké par FCM jusqu'à ce que l'appareil soit hors mode Doze. Et c'est là que le drapeau collapse_key joue un rôle : s'il y a déjà un message avec la même clé de repli (et le même jeton d'enregistrement) stocké et en attente de livraison, l'ancien message est supprimé et le nouveau prend sa place (c'est-à-dire l'ancien message est réduit par le nouveau). Toutefois, si la clé de réduction n'est pas définie, les nouveaux et anciens messages sont stockés pour une livraison future.
Si l'appareil n'est pas connecté à FCM, le message est stocké jusqu'à ce qu'une connexion soit établie (en respectant à nouveau les règles de la clé de repli). Lorsqu'une connexion est établie, FCM transmet tous les messages en attente à l'appareil. Si l'appareil ne se reconnecte jamais (par exemple, s'il a été réinitialisé aux paramètres d'usine), le message finit par expirer et est supprimé du stockage FCM. Le délai d'expiration par défaut est de quatre semaines, sauf si l'indicateur time_to_live est défini.
Pour obtenir plus d'informations sur la livraison d'un message :
Pour obtenir plus d'informations sur la livraison des messages sur les plates-formes Android ou Apple, consultez le tableau de bord des rapports FCM , qui enregistre le nombre de messages envoyés et ouverts sur les appareils Apple et Android, ainsi que des données pour les "impressions" (notifications vues par les utilisateurs) pour Applications Android.
Pour les appareils Android sur lesquels la messagerie par canal direct est activée, si l'appareil ne s'est pas connecté à FCM pendant plus d'un mois, FCM accepte toujours le message mais le rejette immédiatement. Si l'appareil se connecte dans les quatre semaines suivant le dernier message de données que vous lui avez envoyé, votre client reçoit le rappel onDeletedMessages() . L'application peut alors gérer la situation correctement, généralement en demandant une synchronisation complète au serveur d'applications.
Enfin, lorsque FCM tente de transmettre un message à l'appareil et que l'application a été désinstallée, FCM supprime immédiatement ce message et invalide le jeton d'enregistrement. Les tentatives futures d'envoi d'un message à cet appareil entraînent une erreur NotRegistered .
Limitation et mise à l'échelle
Notre objectif est de toujours livrer chaque message envoyé via FCM. Cependant, la livraison de chaque message entraîne parfois une mauvaise expérience utilisateur globale. Dans d'autres cas, nous devons fournir des limites pour garantir que FCM fournit un service évolutif à tous les expéditeurs.
Limitation des messages pliables
Comme décrit ci-dessus, les messages pliables sont des notifications sans contenu conçues pour s'effondrer les unes sur les autres. Dans le cas où un développeur répète trop fréquemment le même message à une application, nous retardons (limitons) les messages pour réduire l'impact sur la batterie d'un utilisateur.
Par exemple, si vous envoyez un grand nombre de nouvelles demandes de synchronisation d'e-mails à un seul appareil, nous pouvons retarder la prochaine demande de synchronisation d'e-mails de quelques minutes afin que l'appareil puisse se synchroniser à un taux moyen inférieur. Cet étranglement est effectué strictement pour limiter l'impact de la batterie subi par l'utilisateur.
Si votre cas d'utilisation nécessite des modèles d'envoi en rafales élevés, les messages non réductibles peuvent être le bon choix. Pour de tels messages, assurez-vous d'inclure le contenu dans ces messages afin de réduire le coût de la batterie.
Nous limitons les messages pliables à une rafale de 20 messages par application et par appareil, avec une recharge de 1 message toutes les 3 minutes.
Limitation du serveur XMPP
Nous limitons le taux auquel vous pouvez vous connecter aux serveurs FCM XMPP à 400 connexions par minute et par projet. Cela ne devrait pas être un problème pour la livraison des messages, mais c'est important pour assurer la stabilité de notre système.
Pour chaque projet, FCM autorise 2500 connexions en parallèle.
Débit maximal de messages vers un seul appareil
Pour Android, vous pouvez envoyer jusqu'à 240 messages/minute et 5 000 messages/heure à un seul appareil. Ce seuil élevé est destiné à permettre des pics de trafic à court terme, par exemple lorsque les utilisateurs interagissent rapidement via le chat. Cette limite empêche les erreurs de logique d'envoi de décharger par inadvertance la batterie d'un appareil.
Pour iOS, nous renvoyons une erreur lorsque le taux dépasse les limites APN.
Limite de messages en amont
Nous limitons les messages en amont à 1 500 000/minute par projet pour éviter de surcharger les serveurs de destination en amont.
Nous limitons les messages en amont par appareil à 1 000/minute pour protéger contre l'épuisement de la batterie dû au mauvais comportement de l'application.
Limite de message de sujet
Le taux d'ajout/de suppression d'abonnements aux sujets est limité à 3 000 RPS par projet.
Pour connaître les taux d'envoi de messages, consultez Limitation de diffusion .
Limitation de diffusion
La diffusion des messages est le processus d'envoi d'un message à plusieurs appareils, par exemple lorsque vous ciblez des sujets et des groupes, ou lorsque vous utilisez l' éditeur de notifications pour cibler des audiences ou des segments d'utilisateurs.
La diffusion des messages n'est pas instantanée et vous avez donc parfois plusieurs diffusions en cours simultanément. Nous limitons le nombre de diffusions simultanées de messages par projet à 1 000. Après cela, nous pouvons rejeter les demandes de diffusion supplémentaires ou différer la diffusion des demandes jusqu'à ce que certaines des diffusions déjà en cours soient terminées.
Le taux de diffusion réel réalisable est influencé par le nombre de projets demandant des diffusions en même temps. Un taux de déploiement de 10 000 RPS pour un projet individuel n'est pas rare, mais ce nombre n'est pas une garantie et résulte de la charge totale du système. Il est important de noter que la capacité de diffusion disponible est répartie entre les projets et non entre les demandes de diffusion. Ainsi, si votre projet a deux diffusions en cours, chaque diffusion ne verra que la moitié du taux de diffusion disponible. La méthode recommandée pour optimiser la vitesse de diffusion consiste à n'avoir qu'une seule diffusion active en cours à la fois.
Les ports FCM et votre pare-feu
Si votre organisation dispose d'un pare-feu pour restreindre le trafic vers ou depuis Internet, vous devez le configurer pour autoriser les appareils mobiles à se connecter à FCM afin que les appareils de votre réseau puissent recevoir des messages. FCM utilise généralement le port 5228, mais il utilise parfois 443, 5229 et 5230.
Pour les appareils se connectant sur votre réseau, FCM ne fournit pas d'adresses IP spécifiques, car notre plage d'adresses IP change trop fréquemment et vos règles de pare-feu pourraient devenir obsolètes, ce qui aurait un impact sur l'expérience de vos utilisateurs. Idéalement, listez les ports 5228-5230 et 443 sans restriction IP. Cependant, si vous devez avoir une restriction IP, vous devez autoriser toutes les adresses IP répertoriées dans goog.json . Cette grande liste est mise à jour régulièrement, et il vous est recommandé de mettre à jour vos règles sur une base mensuelle. Les problèmes causés par les restrictions IP du pare-feu sont souvent intermittents et difficiles à diagnostiquer.
Nous proposons un ensemble de noms de domaine qui peuvent être autorisés à la place des adresses IP. Ces noms d'hôte sont répertoriés ci-dessous. Si nous commençons à utiliser des noms d'hôte supplémentaires, nous mettrons à jour la liste ici. L'utilisation de noms de domaine pour votre règle de pare-feu peut ou non être fonctionnelle dans votre dispositif de pare-feu.
Ports TCP à ouvrir :
- 5228
- 5229
- 5230
- 443
Noms d'hôte à ouvrir :
- mtalk.google.com
- mtalk4.google.com
- mtalk-staging.google.com
- mtalk-dev.google.com
- alt1-mtalk.google.com
- alt2-mtalk.google.com
- alt3-mtalk.google.com
- alt4-mtalk.google.com
- alt5-mtalk.google.com
- alt6-mtalk.google.com
- alt7-mtalk.google.com
- alt8-mtalk.google.com
- android.apis.google.com
- device-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Pare-feu de traduction d'adresses réseau et/ou d'inspection dynamique des paquets :
Si votre réseau implémente la traduction d'adresses réseau (NAT) ou l'inspection dynamique des paquets (SPI), implémentez un délai d'attente de 30 minutes ou plus pour nos connexions sur les ports 5228-5230. Cela nous permet de fournir une connectivité fiable tout en réduisant la consommation de la batterie des appareils mobiles de vos utilisateurs.
Crédits
Selon les fonctionnalités FCM que vous implémentez, vous aurez peut-être besoin des informations d'identification suivantes de votre projet Firebase :
| ID de projet | Un identifiant unique pour votre projet Firebase, utilisé dans les requêtes au point de terminaison HTTP FCM v1. Cette valeur est disponible dans le volet Paramètres de la console Firebase . |
| Jeton d'enregistrement | Une chaîne de jeton unique qui identifie chaque instance d'application cliente. Le jeton d'enregistrement est requis pour la messagerie d'un seul appareil et d'un groupe d'appareils. Notez que les jetons d'enregistrement doivent être gardés secrets. |
| Identifiant de l'expéditeur | Une valeur numérique unique créée lorsque vous créez votre projet Firebase, disponible dans l'onglet Cloud Messaging du volet Paramètres de la console Firebase. L'ID de l'expéditeur est utilisé pour identifier chaque expéditeur qui peut envoyer des messages à l'application cliente. |
| Jeton d'accès | Un jeton OAuth 2.0 de courte durée qui autorise les requêtes à l'API HTTP v1. Ce jeton est associé à un compte de service qui appartient à votre projet Firebase. Pour créer et faire pivoter des jetons d'accès, suivez les étapes décrites dans Autoriser les demandes d'envoi . |
| Clé de serveur (pour les protocoles hérités) | Une clé de serveur qui autorise votre serveur d'applications à accéder aux services Google, y compris l'envoi de messages via les anciens protocoles Firebase Cloud Messaging. Vous obtenez la clé du serveur lorsque vous créez votre projet Firebase. Vous pouvez l'afficher dans l'onglet Cloud Messaging du volet Paramètres de la console Firebase. Important : n'incluez la clé du serveur nulle part dans votre code client. Veillez également à n'utiliser que des clés de serveur pour autoriser votre serveur d'applications. Android, la plate-forme Apple et les clés de navigateur sont rejetées par FCM. |