Firebase Cloud Messaging (FCM) offre un'ampia gamma di opzioni e funzionalità di messaggistica. Le informazioni contenute in questa pagina hanno lo scopo di aiutarti a comprendere i diversi tipi di messaggi FCM e cosa puoi fare con essi.
Tipi di messaggio
Con FCM puoi inviare due tipi di messaggi ai client:
- Messaggi di notifica, a volte considerati "messaggi visualizzati". Questi vengono gestiti automaticamente dall'SDK FCM.
- Messaggi di dati, gestiti dall'app client.
I messaggi di notifica contengono un set predefinito di chiavi visibili all'utente. I messaggi di dati, al contrario, contengono solo le coppie chiave-valore personalizzate definite dall'utente. I messaggi di notifica possono contenere un payload di dati opzionale. Il carico utile massimo per entrambi i tipi di messaggio è 4000 byte, tranne quando si inviano messaggi dalla console Firebase, che impone un limite di 1000 caratteri.
| Usa scenario | Come spedire | |
|---|---|---|
| Messaggio di notifica | L'SDK FCM visualizza il messaggio sui dispositivi degli utenti finali per conto dell'app client quando è in esecuzione in background. Altrimenti, se l'app è in esecuzione in primo piano quando viene ricevuta la notifica, il codice dell'app determina il comportamento. I messaggi di notifica hanno un set predefinito di chiavi visibili all'utente e un payload di dati opzionale di coppie chiave-valore personalizzate. |
|
| Messaggio di dati | L'app client è responsabile dell'elaborazione dei messaggi di dati. I messaggi di dati hanno solo coppie chiave-valore personalizzate senza nomi di chiave riservati (vedi sotto). | In un ambiente attendibile come Cloud Functions o il server delle applicazioni, utilizza Admin SDK o i protocolli server FCM . Nella richiesta di invio, impostare la chiave data . |
Utilizza i messaggi di notifica quando desideri che l'SDK FCM gestisca la visualizzazione automatica di una notifica quando l'app è in esecuzione in background. Utilizza i messaggi di dati quando desideri elaborare i messaggi con il codice dell'app client.
FCM può inviare un messaggio di notifica incluso un payload di dati opzionale. In questi casi, FCM gestisce la visualizzazione del payload delle notifiche e l'app client gestisce il payload dei dati.
Messaggi di notifica
A scopo di test o di marketing e di coinvolgimento degli utenti, puoi inviare messaggi di notifica utilizzando la console Firebase . La console Firebase fornisce test A/B basati sull'analisi per aiutarti a perfezionare e migliorare i messaggi di marketing.
Per inviare messaggi di notifica a livello di codice utilizzando i protocolli Admin SDK o FCM, impostare la chiave notification con il set predefinito necessario di opzioni chiave-valore per la parte visibile all'utente del messaggio di notifica. Ad esempio, ecco un messaggio di notifica in formato JSON in un'app di messaggistica istantanea. L'utente può aspettarsi di vedere un messaggio con il titolo "Portogallo vs. Danimarca" e il testo "grande partita!" sul dispositivo:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}I messaggi di notifica vengono recapitati nella barra delle notifiche quando l'app è in background. Per le app in primo piano, i messaggi vengono gestiti da una funzione di callback.
Consulta la documentazione di riferimento dell'oggetto di notifica del protocollo HTTP v1 per l'elenco completo delle chiavi predefinite disponibili per la creazione di messaggi di notifica.
Messaggi di dati
Imposta la chiave appropriata con le coppie chiave-valore personalizzate per inviare un payload di dati all'app client.
Ad esempio, ecco un messaggio in formato JSON nella stessa app di messaggistica istantanea di cui sopra, in cui le informazioni sono incapsulate nella chiave data comune e si prevede che l'app client interpreti il contenuto:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
} L'esempio precedente mostra l'utilizzo del campo data di livello superiore o comune, che viene interpretato dai client su tutte le piattaforme che ricevono il messaggio. Su ogni piattaforma, l'app client riceve il payload dei dati in una funzione di callback.
Crittografia per i messaggi di dati
L'Android Transport Layer (vedi architettura FCM ) utilizza la crittografia punto-punto. A seconda delle tue esigenze, potresti decidere di aggiungere la crittografia end-to-end ai messaggi di dati. FCM non fornisce una soluzione end-to-end. Tuttavia, sono disponibili soluzioni esterne come Capillary o DTLS .
Messaggi di notifica con payload dati opzionale
Sia a livello di programmazione che tramite la console Firebase, puoi inviare messaggi di notifica che contengono un payload opzionale di coppie chiave-valore personalizzate. Nel compositore delle notifiche , utilizza i campi dati personalizzati in Opzioni avanzate .
Il comportamento dell'app quando si ricevono messaggi che includono sia notifiche che payload di dati dipende dal fatto che l'app sia in background o in primo piano, in sostanza dal fatto che sia attiva o meno al momento della ricezione.
- In background , le app ricevono il payload delle notifiche nella barra delle notifiche e gestiscono il payload dei dati solo quando l'utente tocca la notifica.
- Quando è in primo piano , la tua app riceve un oggetto messaggio con entrambi i payload disponibili.
Ecco un messaggio in formato JSON contenente sia la chiave notification che la chiave data :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}Personalizzazione di un messaggio su più piattaforme
Sia Firebase Admin SDK che il protocollo HTTP FCM v1 consentono alle richieste di messaggio di impostare tutti i campi disponibili nell'oggetto message . Ciò comprende:
- un insieme comune di campi che devono essere interpretati da tutte le istanze dell'app che ricevono il messaggio.
- set di campi specifici della piattaforma, come
AndroidConfigeWebpushConfig, interpretati solo dalle istanze dell'app in esecuzione sulla piattaforma specificata.
I blocchi specifici della piattaforma ti offrono la flessibilità di personalizzare i messaggi per piattaforme diverse per garantire che vengano gestiti correttamente una volta ricevuti. Il backend FCM terrà conto di tutti i parametri specificati e personalizzerà il messaggio per ciascuna piattaforma.
Quando utilizzare i campi comuni
Utilizza i campi comuni quando:
- Targeting per istanze di app su tutte le piattaforme: Apple, Android e Web
- Invio di messaggi ad argomenti
Tutte le istanze dell'app, indipendentemente dalla piattaforma, possono interpretare i seguenti campi comuni:
Quando utilizzare i campi specifici della piattaforma
Utilizza i campi specifici della piattaforma quando desideri:
- Invia campi solo a piattaforme particolari
- Invia campi specifici della piattaforma in aggiunta ai campi comuni
Ogni volta che desideri inviare valori solo a piattaforme particolari, non utilizzare campi comuni; utilizzare campi specifici della piattaforma. Ad esempio, per inviare una notifica solo alle piattaforme Apple e web ma non ad Android, è necessario utilizzare due set di campi separati, uno per Apple e uno per il web.
Quando invii messaggi con opzioni di consegna specifiche, utilizza i campi specifici della piattaforma per impostarli. Se lo desideri, puoi specificare valori diversi per piattaforma. Tuttavia, anche quando desideri impostare essenzialmente lo stesso valore su tutte le piattaforme, devi utilizzare campi specifici della piattaforma. Questo perché ciascuna piattaforma può interpretare il valore in modo leggermente diverso: ad esempio, il time-to-live è impostato su Android come una scadenza in secondi, mentre su Apple è impostato come una data di scadenza.
Esempio: messaggio di notifica con opzioni di consegna specifiche della piattaforma
La seguente richiesta di invio v1 invia un titolo e un contenuto di notifica comuni a tutte le piattaforme, ma invia anche alcune sostituzioni specifiche della piattaforma. Nello specifico la richiesta:
- imposta un time-to-live lungo per le piattaforme Android e Web, impostando la priorità dei messaggi APN (piattaforme Apple) su un valore basso
- imposta i tasti appropriati per definire il risultato del tocco di un utente sulla notifica su Android e Apple: rispettivamente
click_actionecategory.
{
"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"
}
}
}
}Consulta la documentazione di riferimento HTTP v1 per dettagli completi sulle chiavi disponibili nei blocchi specifici della piattaforma nel corpo del messaggio. Per ulteriori informazioni sulla creazione di richieste di invio che contengono il corpo del messaggio, vedere Creazione di richieste di invio .
Opzioni di consegna
FCM fornisce una serie specifica di opzioni di consegna per i messaggi inviati a dispositivi Android e consente opzioni simili sulle piattaforme Apple e sul Web. Ad esempio, il comportamento dei messaggi "comprimibili" è supportato su Android tramite collapse_key di FCM, su Apple tramite apns-collapse-id e su JavaScript/Web tramite Topic . Per i dettagli, vedere le descrizioni in questa sezione e la relativa documentazione di riferimento.
Messaggi non comprimibili e pieghevoli
Un messaggio non comprimibile indica che ogni singolo messaggio viene recapitato al dispositivo. Un messaggio non comprimibile fornisce contenuti utili, al contrario di un messaggio comprimibile come un "ping" privo di contenuto all'app mobile per contattare il server per recuperare i dati.
Alcuni casi d'uso tipici dei messaggi non comprimibili sono i messaggi di chat o i messaggi critici. Ad esempio, in un'app di messaggistica istantanea, vorresti consegnare ogni messaggio, perché ogni messaggio ha contenuti diversi.
Per Android esiste un limite di 100 messaggi che possono essere archiviati senza collassare. Se viene raggiunto il limite, tutti i messaggi archiviati vengono eliminati. Quando il dispositivo torna online, riceve un messaggio speciale che indica che è stato raggiunto il limite. L'app può quindi gestire correttamente la situazione, in genere richiedendo una sincronizzazione completa dal server dell'app.
Un messaggio comprimibile è un messaggio che può essere sostituito da un nuovo messaggio se deve ancora essere recapitato al dispositivo.
Un caso d'uso comune dei messaggi comprimibili sono i messaggi utilizzati per indicare a un'app mobile di sincronizzare i dati dal server. Un esempio potrebbe essere un'app sportiva che aggiorna gli utenti con il punteggio più recente. È rilevante solo il messaggio più recente.
Per contrassegnare un messaggio come comprimibile su Android, includi il parametro collapse_key nel payload del messaggio. Per impostazione predefinita, la chiave di compressione è il nome del pacchetto dell'app registrato nella console Firebase. Il server FCM può archiviare contemporaneamente quattro diversi messaggi comprimibili per dispositivo, ciascuno con una chiave di compressione diversa. Se superi questo numero, FCM conserva solo quattro chiavi di compressione, senza garanzie su quali verranno mantenute.
I messaggi di argomento senza payload sono comprimibili per impostazione predefinita. I messaggi di notifica sono sempre comprimibili e ignoreranno il parametro collapse_key .
Quale dovrei usare?
I messaggi comprimibili sono una scelta migliore dal punto di vista delle prestazioni, a condizione che la tua app non debba necessariamente utilizzare messaggi non comprimibili. Tuttavia, se utilizzi messaggi comprimibili, ricorda che FCM consente l'utilizzo da parte di FCM solo di un massimo di quattro diverse chiavi di compressione per token di registrazione in un dato momento. Non devi superare questo numero, altrimenti potrebbe causare conseguenze imprevedibili.
| Usa scenario | Come spedire | |
|---|---|---|
| Non pieghevole | Ogni messaggio è importante per l'app client e deve essere recapitato. | Ad eccezione dei messaggi di notifica, tutti i messaggi non sono comprimibili per impostazione predefinita. |
| Collassabile | Quando è presente un messaggio più recente che rende irrilevante per l'app client un messaggio correlato precedente, FCM sostituisce il messaggio precedente. Ad esempio: messaggi utilizzati per avviare una sincronizzazione dei dati dal server o messaggi di notifica obsoleti. | Imposta il parametro appropriato nella richiesta del messaggio:
|
Impostazione della priorità di un messaggio
Hai due opzioni per assegnare la priorità di consegna ai messaggi downstream: priorità normale e alta. Sebbene il comportamento differisca leggermente da una piattaforma all'altra, la consegna dei messaggi normali e ad alta priorità funziona in questo modo:
Priorità normale. I messaggi con priorità normale vengono recapitati immediatamente quando l'app è in primo piano. Per le app in background, la consegna potrebbe subire ritardi. Per i messaggi meno urgenti, come le notifiche di nuove email, la sincronizzazione dell'interfaccia utente o la sincronizzazione dei dati delle app in background, scegli la priorità di recapito normale.
Priorità alta. FCM tenta di consegnare immediatamente i messaggi ad alta priorità anche se il dispositivo è in modalità Doze. I messaggi ad alta priorità riguardano contenuti visibili all'utente sensibili al fattore tempo.
Ecco un esempio di un normale messaggio con priorità inviato tramite il protocollo FCM HTTP v1 per notificare a un abbonato alla rivista che è disponibile per il download un nuovo contenuto:
{
"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"
}
}
}
}
Per ulteriori dettagli specifici della piattaforma sull'impostazione della priorità dei messaggi:
- Documentazione APN
- Imposta e gestisci la priorità dei messaggi (Android)
- Urgenza del messaggio push web
Impostazione della durata di un messaggio
FCM solitamente recapita i messaggi immediatamente dopo l'invio. Tuttavia, ciò potrebbe non essere sempre possibile. Ad esempio, se la piattaforma è Android, il dispositivo potrebbe essere spento, offline o comunque non disponibile. Oppure FCM potrebbe ritardare intenzionalmente i messaggi per evitare che un'app consumi risorse eccessive e influisca negativamente sulla durata della batteria.
Quando ciò accade, FCM archivia il messaggio e lo consegna non appena possibile. Sebbene ciò vada bene nella maggior parte dei casi, ci sono alcune app per le quali un messaggio in ritardo potrebbe anche non essere mai recapitato. Ad esempio, se il messaggio riguarda una chiamata in arrivo o una notifica di chat video, ha significato solo per un breve periodo di tempo prima che la chiamata venga terminata. Oppure se il messaggio è un invito ad un evento, è inutile se ricevuto dopo la fine dell'evento.
Su Android e Web/JavaScript è possibile specificare la durata massima di un messaggio. Il valore deve avere una durata compresa tra 0 e 2.419.200 secondi (28 giorni) e corrisponde al periodo di tempo massimo per il quale FCM archivia e tenta di recapitare il messaggio. Per le richieste che non contengono questo campo viene impostato automaticamente il periodo massimo di quattro settimane.
Ecco alcuni possibili utilizzi di questa funzionalità:
- Chiamate in arrivo tramite chat video
- Eventi di invito in scadenza
- Eventi del calendario
Un altro vantaggio di specificare la durata di un messaggio è che FCM non limita mai i messaggi con un valore di durata pari a 0 secondi. In altre parole, FCM garantisce il massimo impegno per i messaggi che devono essere consegnati "ora o mai più". Tieni presente che un valore time_to_live pari a 0 significa che i messaggi che non possono essere recapitati immediatamente verranno scartati. Tuttavia, poiché tali messaggi non vengono mai archiviati, ciò fornisce la migliore latenza per l'invio di messaggi di notifica.
Ecco un esempio di richiesta che include TTL:
{
"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"
}
}
}
}Durata di un messaggio
Quando un server app pubblica un messaggio su FCM e riceve in risposta un ID messaggio, non significa che il messaggio sia già stato recapitato al dispositivo. Significa piuttosto che è stato accettato per la consegna. Ciò che accade al messaggio dopo che è stato accettato dipende da molti fattori.
Nella migliore delle ipotesi, se il dispositivo è connesso a FCM, lo schermo è acceso e non ci sono restrizioni di limitazione, il messaggio viene recapitato immediatamente.
Se il dispositivo è connesso ma in modalità Doze, FCM memorizza un messaggio a bassa priorità finché il dispositivo non esce da Doze. Ed è qui che gioca un ruolo il flag collapse_key : se c'è già un messaggio con la stessa chiave di collasso (e token di registrazione) archiviato e in attesa di consegna, il vecchio messaggio viene scartato e il nuovo messaggio prende il suo posto (ovvero, il vecchio il messaggio viene compresso da quello nuovo). Tuttavia, se la chiave di compressione non è impostata, sia il nuovo che il vecchio messaggio verranno archiviati per il recapito futuro.
Se il dispositivo non è connesso a FCM, il messaggio viene archiviato finché non viene stabilita una connessione (sempre rispettando le regole della chiave di compressione). Quando viene stabilita una connessione, FCM consegna tutti i messaggi in sospeso al dispositivo. Se il dispositivo non viene mai più connesso (ad esempio, se è stato ripristinato il valore di fabbrica), il messaggio prima o poi scade e viene eliminato dall'archivio FCM. Il timeout predefinito è quattro settimane, a meno che non sia impostato il flag time_to_live .
Per ottenere maggiori informazioni sulla consegna di un messaggio:
Per ottenere maggiori informazioni sulla consegna dei messaggi su piattaforme Android o Apple, consulta il dashboard di reporting FCM , che registra il numero di messaggi inviati e aperti su dispositivi Apple e Android, insieme ai dati per le "impressioni" (notifiche visualizzate dagli utenti) per App Android.
Per i dispositivi Android con la messaggistica diretta del canale abilitata, se il dispositivo non si è connesso a FCM per più di un mese, FCM accetta comunque il messaggio ma lo scarta immediatamente. Se il dispositivo si connette entro quattro settimane dall'ultimo messaggio di dati che gli hai inviato, il tuo client riceve la richiamata onDeletedMessages() . L'app può quindi gestire correttamente la situazione, in genere richiedendo una sincronizzazione completa dal server dell'app.
Infine, quando FCM tenta di recapitare un messaggio al dispositivo e l'app viene disinstallata, FCM scarta immediatamente il messaggio e invalida il token di registrazione. I futuri tentativi di inviare un messaggio a quel dispositivo genereranno un errore NotRegistered .
Throttling e ridimensionamento
Il nostro obiettivo è consegnare sempre ogni messaggio inviato tramite FCM. Tuttavia, la consegna di ogni messaggio a volte comporta un'esperienza utente complessiva scadente. In altri casi, dobbiamo fornire dei limiti per garantire che FCM fornisca un servizio scalabile per tutti i mittenti.
Limitazione dei messaggi comprimibili
Come descritto in precedenza, i messaggi comprimibili sono notifiche prive di contenuto progettate per comprimersi una sull'altra. Nel caso in cui uno sviluppatore ripeta lo stesso messaggio a un'app troppo frequentemente, ritardiamo (limitiamo) i messaggi per ridurre l'impatto sulla batteria dell'utente.
Ad esempio, se invii un gran numero di nuove richieste di sincronizzazione e-mail a un singolo dispositivo, potremmo ritardare la successiva richiesta di sincronizzazione e-mail di alcuni minuti in modo che il dispositivo possa sincronizzarsi a una velocità media inferiore. Questa limitazione viene eseguita rigorosamente per limitare l'impatto della batteria sperimentato dall'utente.
Se il tuo caso d'uso richiede modelli di invio a burst elevato, i messaggi non comprimibili potrebbero essere la scelta giusta. Per tali messaggi, assicurati di includere il contenuto in tali messaggi per ridurre il costo della batteria.
Limitiamo i messaggi comprimibili a un massimo di 20 messaggi per app per dispositivo, con un rifornimento di 1 messaggio ogni 3 minuti.
Limitazione del server XMPP
Limitiamo la velocità con cui puoi connetterti ai server FCM XMPP a 400 connessioni al minuto per progetto. Questo non dovrebbe rappresentare un problema per la consegna dei messaggi, ma è importante per garantire la stabilità del sistema. Per ogni progetto, FCM consente 2500 connessioni in parallelo.
Per la messaggistica upstream con XMPP, FCM limita i messaggi upstream a 1.500.000/minuto per progetto per evitare di sovraccaricare i server di destinazione upstream.
Limitiamo i messaggi upstream per dispositivo a 1.000 al minuto per proteggere dal consumo della batteria dovuto a comportamenti scorretti delle app.
Velocità massima dei messaggi per un singolo dispositivo
Per Android puoi inviare fino a 240 messaggi al minuto e 5.000 messaggi all'ora a un singolo dispositivo. Questa soglia elevata ha lo scopo di consentire picchi di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente tramite chat. Questo limite impedisce agli errori nell'invio della logica di scaricare inavvertitamente la batteria di un dispositivo.
Per iOS, restituiamo un errore quando la velocità supera i limiti APN.
Limite dei messaggi sull'argomento
La tariffa di aggiunta/rimozione dell'abbonamento all'argomento è limitata a 3.000 QPS per progetto.
Per le tariffe di invio dei messaggi, consulta Limitazione del fanout .
Throttling del fanout
Il fanout dei messaggi è il processo di invio di un messaggio a più dispositivi, ad esempio quando scegli come target argomenti e gruppi o quando utilizzi il compositore di notifiche per scegliere come target segmenti di pubblico o utenti.
Il fanout dei messaggi non è istantaneo e quindi occasionalmente si verificano più fanout in corso contemporaneamente. Limitiamo il numero di fanout di messaggi simultanei per progetto a 1.000. Successivamente, potremmo rifiutare ulteriori richieste di fanout o rinviare il fanout delle richieste fino al completamento di alcuni dei fanout già in corso.
Il tasso di fanout effettivo ottenibile è influenzato dal numero di progetti che richiedono fanout contemporaneamente. Un tasso di fanout di 10.000 QPS per un singolo progetto non è raro, ma tale numero non è una garanzia ed è il risultato del carico totale sul sistema. È importante notare che la capacità di fanout disponibile è suddivisa tra progetti e non tra richieste di fanout. Pertanto, se il tuo progetto ha due fanout in corso, ogni fanout vedrà solo la metà della frequenza di fanout disponibile. Il modo consigliato per massimizzare la velocità del fanout è avere un solo fanout attivo in corso alla volta.
Porte FCM e il tuo firewall
Se la tua organizzazione dispone di un firewall per limitare il traffico da o verso Internet, devi configurarlo per consentire ai dispositivi mobili di connettersi con FCM affinché i dispositivi sulla tua rete possano ricevere messaggi. FCM utilizza in genere la porta 5228, ma a volte utilizza 443, 5229 e 5230.
Per i dispositivi che si connettono alla tua rete, FCM non fornisce IP specifici perché il nostro intervallo IP cambia troppo frequentemente e le regole del firewall potrebbero diventare obsolete, influenzando l'esperienza degli utenti. Idealmente, inserire nella lista consentita le porte 5228-5230 e 443 senza restrizioni IP. Tuttavia, se è necessaria una restrizione IP, è necessario inserire nella lista consentita tutti gli indirizzi IP elencati in goog.json . Questo ampio elenco viene aggiornato regolarmente e ti consigliamo di aggiornare le tue regole su base mensile. I problemi causati dalle restrizioni IP del firewall sono spesso intermittenti e difficili da diagnosticare.
Offriamo una serie di nomi di dominio che possono essere inseriti nella lista consentita al posto degli indirizzi IP. Tali nomi host sono elencati di seguito. Se iniziamo a utilizzare nomi host aggiuntivi, aggiorneremo l'elenco qui. L'utilizzo dei nomi di dominio per la regola del firewall potrebbe essere funzionale o meno nel dispositivo firewall.
Porte TCP da aprire:
- 5228
- 5229
- 5230
- 443
Nomi host da aprire:
- 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
- dispositivo-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Firewall Network Address Translation e/o Stateful Packet Inspection:
Se la tua rete implementa Network Address Translation (NAT) o Stateful Packet Inspection (SPI), implementa un timeout di 30 minuti o più per le nostre connessioni sulle porte 5228-5230. Ciò ci consente di fornire una connettività affidabile riducendo al contempo il consumo della batteria dei dispositivi mobili dei tuoi utenti.
Credenziali
A seconda delle funzionalità FCM che implementi, potresti aver bisogno delle seguenti credenziali dal tuo progetto Firebase:
| Identificativo del progetto | Un identificatore univoco per il tuo progetto Firebase, utilizzato nelle richieste all'endpoint HTTP FCM v1. Questo valore è disponibile nel riquadro Impostazioni della console Firebase . |
| Token di registrazione | Una stringa token univoca che identifica ogni istanza dell'app client. Il token di registrazione è richiesto per la messaggistica di un singolo dispositivo e di un gruppo di dispositivi. Tieni presente che i token di registrazione devono essere mantenuti segreti. |
| identità del mittente | Un valore numerico univoco creato quando crei il tuo progetto Firebase, disponibile nella scheda Messaggistica cloud del riquadro Impostazioni della console Firebase. L'ID mittente viene utilizzato per identificare ciascun mittente che può inviare messaggi all'app client. |
| Token di accesso | Un token OAuth 2.0 di breve durata che autorizza le richieste all'API HTTP v1. Questo token è associato a un account di servizio che appartiene al tuo progetto Firebase. Per creare e ruotare i token di accesso, seguire i passaggi descritti in Autorizzare le richieste di invio . |
| Chiave del server (per protocolli legacy **deprecati**) | Una chiave server che autorizza il server dell'app ad accedere ai servizi Google, incluso l'invio di messaggi tramite i protocolli legacy Firebase Cloud Messaging deprecati. Importante: non includere la chiave del server in nessun punto del codice client. Inoltre, assicurati di utilizzare solo le chiavi del server per autorizzare il server dell'app. Le chiavi Android, piattaforma Apple e browser vengono rifiutate da FCM. |