Tentang Pesan FCM

Firebase Cloud Messaging (FCM) menawarkan beragam kemampuan dan opsi pengiriman pesan. Informasi di halaman ini dimaksudkan untuk membantu Anda memahami berbagai jenis pesan FCM, serta apa yang dapat Anda lakukan dengan jenis pesan tersebut.

Jenis pesan

Dengan FCM, Anda dapat mengirim 2 jenis pesan ke klien:

  • Pesan notifikasi, terkadang dianggap sebagai "pesan tampilan". Pesan ini ditangani oleh FCM SDK secara otomatis.
  • Pesan data, yang ditangani oleh aplikasi klien.

Pesan notifikasi memiliki serangkaian kunci bawaan yang terlihat oleh pengguna. Sebaliknya, pesan data hanya memuat key-value pair kustom buatan pengguna. Pesan notifikasi bisa berisi payload data opsional. Payload maksimum untuk kedua jenis pesan tersebut berukuran 4KB, kecuali saat mengirim pesan dari Firebase console, yang memberlakukan batas 1.024 karakter.

Skenario penggunaan Cara mengirim
Pesan notifikasi FCM secara otomatis menampilkan pesan ke perangkat pengguna akhir atas nama aplikasi klien. Pesan notifikasi memiliki serangkaian kunci bawaan yang terlihat oleh pengguna dan payload data opsional untuk key-value pair kustom.
  1. Dalam lingkungan tepercaya, seperti Cloud Functions atau server aplikasi Anda, gunakan Admin SDK atau Protokol Server FCM: Setel kunci notification. Dapat memiliki payload data opsional. Selalu dapat diciutkan.
  2. Gunakan Notifications composer: Masukkan Teks Pesan, Judul, dll., lalu kirim. Tambahkan payload data opsional dengan memasukkan Data kustom.
Pesan data Aplikasi klien bertanggung jawab memproses pesan data. Pesan data hanya memuat key-value pair kustom. Dalam lingkungan tepercaya, seperti Cloud Functions atau server aplikasi Anda, gunakan Admin SDK atau Protokol Server FCM: Setel kunci data saja.

Gunakan pesan notifikasi jika Anda ingin FCM menangani penampilan notifikasi atas nama aplikasi klien. Gunakan pesan data jika Anda ingin memproses pesan di aplikasi klien.

FCM dapat mengirim pesan notifikasi yang mencakup payload data opsional. Dalam kasus semacam ini, FCM menangani penampilan payload notifikasi, sedangkan aplikasi klien menangani payload data.

Pesan notifikasi

Untuk pengujian atau pemasaran dan pendorong interaksi pengguna, Anda dapat mengirim pesan notifikasi menggunakan Firebase console.

Untuk mengirim pesan notifikasi secara terprogram menggunakan Admin SDK atau protokol FCM, setel kunci notification dengan serangkaian opsi key-value bawaan yang diperlukan untuk bagian pesan notifikasi yang terlihat oleh pengguna. Misalnya, berikut ini pesan notifikasi berformat JSON dalam aplikasi IM. Pengguna bisa berharap akan menemukan pesan dengan judul "Portugal vs Denmark" dan teks "great match!" pada perangkat:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

Pesan notifikasi disampaikan ke baki notifikasi saat aplikasi berjalan di latar belakang. Untuk aplikasi yang berjalan di latar depan, pesan ditangani oleh callback ini:

  • didReceiveRemoteNotification: di iOS
  • onMessageReceived() di Android. Kunci notification dalam paket data ini berisi notifikasi.
  • onMessage() di web/JavaScript.

Lihat dokumentasi referensi untuk mengetahui daftar lengkap kunci bawaan yang tersedia untuk membuat pesan notifikasi:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Contoh di atas menunjukkan penggunaan kolom data tingkat atas atau umum, yang ditafsirkan oleh klien pada semua platform yang menerima pesan tersebut. Pada setiap platform, aplikasi klien menerima payload data di callback yang sesuai:

  • Di Android, aplikasi klien menerima pesan data dalam onMessageReceived() dan dapat menangani key-value pair sebagaimana mestinya. Payload data bisa diambil di dalam Intent yang digunakan untuk meluncurkan aktivitas. Lihat Menerima Pesan di Aplikasi Android.

  • Di iOS, payload data ditemukan di didReceiveRemoteNotification: . Lihat Menerima Pesan di Klien iOS.

  • Untuk klien Web/JavaScript, payload data diterima di onMessage() saat halaman berada di latar depan. Saat aplikasi web berjalan di latar belakang, payload dikirimkan ke penangan pesan latar belakang pada pekerja layanan. Lihat Menerima Pesan di Klien JavaScript.

Pesan notifikasi dengan payload data opsional

Baik secara terprogram atau melalui Firebase console, Anda dapat mengirim pesan notifikasi yang berisi payload opsional key-value pair kustom. Dalam Notifications Composer, gunakan kolom Data kustom di Opsi lanjutan.

Perilaku aplikasi saat menerima pesan yang memuat payload data dan notifikasi bergantung pada apakah aplikasi itu berjalan di latar belakang atau latar depan. Intinya, apakah aplikasi aktif atau tidak pada saat menerima pesan.

  • Saat berjalan di latar belakang, aplikasi menerima payload notifikasi di baki notifikasi, dan hanya menangani payload data saat pengguna menge-tap notifikasi.
  • Saat berjalan di latar depan, aplikasi Anda menerima objek pesan dengan kedua payload yang tersedia.

Berikut adalah pesan berformat JSON yang memuat kunci notification dan juga kunci data:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Menyesuaikan pesan di seluruh platform

Pesan yang dikirim melalui protokol HTTP FCM v1 dapat berisi 2 jenis key pair JSON:

  • sekumpulan kunci umum untuk ditafsirkan oleh semua instance aplikasi yang menerima pesan tersebut.
  • blok kunci khusus platform yang ditafsirkan hanya oleh instance aplikasi yang berjalan pada platform tertentu.

Blok khusus platform memberikan Anda fleksibilitas dalam menyesuaikan pesan untuk berbagai platform, guna memastikan pesan ditangani dengan benar saat diterima. Dalam banyak skenario, cukup masuk akal untuk menggunakan kunci umum dan kunci khusus platform dalam pesan tertentu.

Kapan kunci umum digunakan

  • Kapan pun Anda menargetkan instance aplikasi di semua platform, baik di iOS, Android, dan web
  • Saat Anda mengirim pesan ke topik

Kunci umum yang ditafsirkan oleh semua instance aplikasi terlepas dari platformnya adalah message.notification.title, message.notification.body, dan message.data.

Kapan kunci khusus platform digunakan

  • Jika Anda ingin mengirim kolom ke platform tertentu saja
  • Untuk mengirim kolom khusus platform selain kunci umum

Jika Anda ingin mengirim nilai ke platform tertentu saja, jangan gunakan kunci umum; gunakan blok kunci khusus platform. Misalnya, untuk mengirim notifikasi ke iOS dan web saja, namun tidak ke Android, Anda harus menggunakan 2 blok kunci terpisah, yaitu 1 untuk iOS dan 1 lagi untuk web.

Saat Anda mengirim pesan dengan opsi pengiriman tertentu, gunakan kunci khusus platform untuk menetapkannya. Anda dapat menentukan nilai yang berbeda per platform jika mau; tetapi meskipun Anda ingin menetapkan nilai yang sama pada platform, Anda harus menggunakan kunci khusus platform. Hal ini disebabkan karena setiap platform mungkin menafsirkan nilai sedikit berbeda. Misalnya, waktu aktif ditetapkan di Android sebagai waktu berakhir dalam hitungan detik, sedangkan pada iOS ditetapkan sebagai tanggal habis masa berlaku.

Contoh: pesan notifikasi dengan opsi pengiriman khusus platform

Permintaan kirim v1 berikut mengirimkan judul notifikasi umum dan konten ke semua platform, tetapi juga mengirimkan beberapa penggantian khusus platform. Secara khusus, permintaan:

  • menetapkan waktu aktif yang lama untuk platform Android dan Web, sekaligus menetapkan prioritas pesan APN (iOS) ke setelan rendah
  • menetapkan kunci yang sesuai untuk menentukan hasil tap pengguna pada notifikasi di Android dan iOS — click_action, dan category secara berturut-turut.
{
  "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"
       }
     }
   }
 }

Lihat dokumentasi referensi HTTP v1 untuk mengetahui detail lengkap tentang kunci yang tersedia di blok khusus platform dalam isi pesan. Untuk informasi lebih lanjut tentang cara membuat permintaan kirim yang berisi isi pesan, lihat Membuat Permintaan Kirim.

Opsi pengiriman

FCM menyediakan sekumpulan opsi pengiriman khusus untuk pesan yang dikirim ke perangkat Android, dan memungkinkan opsi serupa di iOS dan web. Misalnya, perilaku pesan yang "dapat diciutkan" didukung di perangkat Android melalui collapse_key FCM, di iOS melalui apns-collapse-id, dan di JavaScript/Web melalui Topic. Untuk mengetahui detailnya, lihat deskripsi di bagian ini dan dokumentasi referensi yang terkait.

Pesan yang dapat dan tidak dapat diciutkan

Pesan yang tidak dapat diciutkan menunjukkan bahwa setiap pesan dikirimkan ke perangkat. Pesan yang tidak dapat diciutkan mengirimkan beberapa konten berguna, bukan pesan yang dapat diciutkan seperti "ping" bebas konten, ke aplikasi seluler untuk menghubungi server agar mengambil data.

Beberapa kasus penggunaan umum dari pesan yang dapat diciutkan adalah pesan chat dan pesan penting. Misalnya, pada aplikasi IM, Anda ingin mengirimkan setiap pesan, karena setiap pesan memiliki konten berbeda.

Untuk Android, ada batas 100 pesan yang bisa disimpan tanpa menciutkan. Jika batas ini tercapai, semua pesan yang disimpan akan dihapus. Saat kembali online, perangkat akan menerima pesan khusus yang memberitahukan bahwa batas telah tercapai. Selanjutnya, aplikasi bisa menangani situasi ini dengan tepat, umumnya dengan meminta sinkronisasi penuh dari server aplikasi.

Pesan yang dapat diciutkan adalah pesan yang dapat diganti dengan pesan baru jika pesan tersebut belum dikirimkan ke perangkat.

Kasus penggunaan umum dalam pesan yang dapat diciutkan adalah pesan digunakan untuk memberi tahu aplikasi seluler untuk menyinkronkan data dari server. Contohnya adalah aplikasi olahraga yang mengirimkan informasi skor pertandingan terbaru kepada pengguna. Hanya pesan terbaru yang dianggap relevan.

Untuk menandai pesan sebagai dapat diciutkan di Android, sertakan parameter collapse_key dalam payload pesan. FCM mendukung maksimal 4 kunci penciutan berbeda per perangkat Android yang akan digunakan oleh server aplikasi pada waktu yang ditentukan. Dengan kata lain, server FCM dapat menyimpan 4 pesan berbeda yang bisa diciutkan per perangkat secara bersamaan, masing-masing dengan kunci penciutan berbeda. Jika Anda melampaui angka ini, FCM hanya akan menyimpan 4 kunci penciutan, tanpa jaminan kunci mana yang akan disimpan.

Mana yang harus saya gunakan?

Pesan yang dapat diciutkan merupakan pilihan yang lebih baik dari sudut pandang performa, apabila aplikasi Anda tidak perlu menggunakan pesan yang tidak dapat diciutkan. Akan tetapi, jika Anda menggunakan pesan yang dapat diciutkan, ingatlah bahwa FCM hanya mengizinkan maksimum 4 kunci penciutan berbeda untuk digunakan oleh server koneksi per token pendaftaran pada suatu waktu tertentu. Anda tidak boleh melampaui jumlah ini; jika tidak, mungkin timbul konsekuensi yang tak bisa diprediksi.

Skenario penggunaan Cara mengirim
Tidak dapat diciutkan Setiap pesan penting bagi aplikasi klien dan harus dikirimkan. Kecuali untuk pesan notifikasi, semua pesan tidak dapat diciutkan secara default.
Dapat diciutkan Jika ada pesan baru yang menjadikan pesan lama dan terkait tidak relevan bagi aplikasi klien, FCM akan mengganti pesan lama. Misalnya: pesan yang digunakan untuk memulai sinkronisasi data dari server, atau pesan notifikasi yang sudah lama. Tetapkan parameter yang sesuai dalam permintaan pesan Anda:
  • collapseKey di Android
  • apns-collapse-id di iOS
  • Topic di Web
  • collapse_key dalam protokol lama (semua platform)

Menetapkan prioritas pesan

Anda memiliki 2 opsi untuk menetapkan prioritas pengiriman ke pesan downstream di Android: prioritas normal dan tinggi. Pengiriman pesan berprioritas normal dan tinggi berfungsi sebagai berikut:

  • Prioritas normal. Ini adalah prioritas default untuk pesan data. Pesan berprioritas normal segera dikirim saat aplikasi berjalan di latar depan. Saat perangkat sedang dalam mode Istirahat atau aplikasi dalam mode aplikasi standby, pengiriman mungkin ditunda untuk menghemat baterai. Untuk pesan yang kurang mendesak dari segi waktu, misalnya notifikasi email baru, selalu menyinkronkan UI, atau menyinkronkan data aplikasi di latar belakang, pilihlah prioritas pengiriman normal.

    Saat menerima pesan berprioritas normal di Android yang meminta sinkronisasi data latar belakang untuk aplikasi, Anda harus menjadwalkan tugas FJD atau JobIntentService untuk menanganinya saat jaringan tersedia.

  • Prioritas tinggi. FCM berusaha segera mengirimkan pesan berprioritas tinggi, yang membuat layanan FCM membangunkan perangkat yang sedang tertidur jika diperlukan, dan menjalankan beberapa pemrosesan terbatas (termasuk akses jaringan yang sangat terbatas). Pesan berprioritas tinggi umumnya menimbulkan interaksi pengguna dengan aplikasi Anda. Jika FCM mendeteksi pola yang tidak ada, pesan Anda mungkin tidak diprioritaskan.

    Karena sebagian kecil populasi seluler Android menggunakan jaringan latensi tinggi, jangan buka koneksi ke server Anda sebelum menampilkan notifikasi. Memanggil kembali ke server sebelum akhir waktu pemrosesan yang diizinkan bisa berisiko bagi pengguna pada jaringan latensi tinggi. Atau, sertakan konten notifikasi dalam pesan FCM dan segera tampilkan. Jika Anda harus menyinkronkan tambahan konten dalam aplikasi di Android, Anda dapat menjadwalkan tugas FJD atau JobIntentService untuk menanganinya di latar belakang.

Berikut adalah contoh pesan berprioritas normal yang dikirim melalui protokol HTTP v1 FCM untuk memberi tahu pelanggan majalah bahwa konten baru siap didownload:

{
  "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"
      }
    }
  }
}

Untuk mengetahui detail selengkapnya tentang platform khusus terkait setelan prioritas pesan:

Menetapkan masa aktif pesan

FCM biasanya mengirimkan pesan segera setelah pesan dikirim. Namun, hal tersebut terkadang tidak memungkinkan untuk dilakukan. Misalnya, jika platformnya adalah Android, perangkat mungkin dimatikan, offline, atau tidak tersedia. Atau FCM mungkin sengaja menunda pesan agar aplikasi tidak menggunakan resource secara berlebihan dan berpengaruh negatif pada masa pakai baterai.

Jika ini terjadi, FCM akan menyimpan pesan dan mengirimkannya segera setelah kondisinya memungkinkan. Meskipun dalam kebanyakan kasus hal ini tidak apa-apa, ada beberapa aplikasi yang tidak mengizinkan keterlambatan pengiriman pesan. Misalnya, untuk notifikasi panggilan masuk atau video chat, pesan hanya bermakna untuk periode waktu yang singkat sebelum panggilan tersebut diakhiri. Atau jika pesan itu merupakan undangan ke sebuah acara, pesan tidak akan berguna jika diterima setelah acaranya berakhir.

Di Android dan Web/JavaScript, Anda dapat menentukan masa aktif maksimum suatu pesan. Nilainya harus berupa durasi dari 0 hingga 2.419.200 detik (28 hari), dan sama dengan periode waktu maksimum bagi FCM untuk menyimpan dan mencoba mengirimkan pesan. Permintaan yang tidak memuat kolom ini akan di-default-kan ke periode maksimum 4 minggu.

Berikut adalah beberapa kemungkinan penggunaan fitur ini:

  • Panggilan masuk video chat
  • Acara undangan yang akan segera berakhir waktunya
  • Acara kalender

Keuntungan lain dari penetapan masa aktif pesan adalah FCM tidak akan pernah mencegat pesan yang memiliki nilai waktu aktif selama 0 detik. Dengan kata lain, FCM menjamin upaya terbaik untuk pesan yang harus dikirimkan "sekarang atau tidak sama sekali". Perlu diingat bahwa nilai time_to_live 0 berarti pesan yang tidak dapat segera dikirimkan akan dihapus. Namun, karena pesan seperti itu tidak pernah disimpan, hal ini memberikan latensi terbaik untuk mengirim pesan notifikasi.

Berikut adalah contoh permintaan yang mencakup 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"
      }
    }
  }
}

Menerima pesan dari beberapa pengirim

FCM membuat beberapa pihak dapat mengirimkan pesan ke aplikasi klien yang sama. Misalnya, anggaplah aplikasi klien adalah agregator artikel dengan beberapa kontributor, dan masing-masing harus mampu mengirim pesan ketika memublikasikan artikel baru. Pesan ini mungkin mengandung URL sehingga aplikasi klien dapat mendownload artikel. Dan bukannya memusatkan semua aktivitas pengiriman di 1 lokasi, FCM memberi Anda kemampuan untuk mengizinkan setiap kontributor mengirimkan pesannya sendiri.

Untuk mengaktifkan fitur ini, pastikan Anda memiliki setiap ID pengirim milik pengirim. Saat pengajuan pendaftaran, aplikasi klien akan mengambil token beberapa kali, setiap kali dengan ID pengirim berbeda di kolom audience, dengan menggunakan metode pengambilan token untuk platform tertentu:

Terakhir, bagikan token pendaftaran dengan pengirim yang terkait dan pengirim akan dapat mengirim pesan ke aplikasi klien menggunakan kunci autentikasinya sendiri.

Perhatikan bahwa ada batasan 100 pengirim serempak.

Masa aktif pesan

Saat server aplikasi memposting pesan ke FCM dan menerima kembali ID pesan, itu tidak berarti bahwa pesan sudah dikirimkan ke perangkat. Hal itu hanya berarti bahwa pesan telah diterima untuk dikirimkan. Apa yang terjadi pada pesan setelah diterima dipengaruhi oleh banyak faktor.

Dalam skenario kasus terbaik, jika perangkat terhubung dengan FCM, layarnya menyala, dan tidak ada pembatasan pencegatan, pesan akan segera dikirimkan.

Jika perangkat terhubung namun dalam mode Istirahat, pesan berprioritas rendah akan disimpan oleh FCM hingga perangkat keluar dari mode Istirahat. Di sinilah tanda collapse_key berperan: jika telah ada pesan dengan kunci penciutan (dan token pendaftaran) yang sama yang disimpan dan menunggu dikirimkan, pesan lama akan dihapus dan pesan baru akan menggantikannya (artinya, pesan lama diciutkan oleh pesan baru). Namun, jika kunci penciutan tidak disetel, baik pesan lama maupun pesan baru akan disimpan untuk dikirimkan kemudian.

Jika perangkat tidak terhubung ke FCM, pesan akan disimpan hingga koneksi dibuat (lagi-lagi dengan mematuhi aturan kunci penciutan). Saat koneksi dibuat, FCM akan mengirimkan semua pesan yang tertunda ke perangkat. Jika perangkat tidak pernah terhubung kembali (misalnya, jika perangkat disetel ulang ke setelan pabrik), pesan akan kehabisan waktu dan dihapus dari penyimpanan FCM. Waktu tunggu default adalah 4 minggu, kecuali jika tanda time_to_live disetel.

Untuk mendapatkan lebih banyak informasi tentang pengiriman pesan:

  • Untuk Android: Jika Anda ingin diberi tahu saat aplikasi berhasil menerima pesan, Anda dapat menggunakan fungsi delivery_receipt_requested dengan mengikuti panduan. Ini mengharuskan Anda menyetel server XMPP.
  • Untuk Android, iOS, dan Web: Anda dapat menggunakan InstanceID API untuk memeriksa tanggal terbaru, bahwa perangkat yang Anda targetkan melalui token pendaftaran FCM telah membuat koneksi dengan FCM.

Jika perangkat tidak terhubung ke FCM selama lebih dari 1 bulan, FCM tetap menerima pesan, namun akan segera menghapusnya. Jika perangkat terhubung dalam waktu 4 minggu sejak pesan data terakhir dikirim ke sana, klien Anda akan menerima callback onDeletedMessages(). Selanjutnya, aplikasi bisa menangani situasi ini dengan tepat, umumnya dengan meminta sinkronisasi penuh dari server aplikasi.

Terakhir, ketika FCM mencoba mengirimkan pesan ke perangkat dan aplikasi sudah di-uninstal, FCM akan langsung menghapus pesan dan membatalkan validasi token pendaftaran. Upaya mendatang untuk mengirim pesan ke perangkat tersebut akan menghasilkan error NotRegistered.

Port FCM dan firewall Anda

Jika organisasi Anda memiliki firewall untuk membatasi traffic ke atau dari Internet, Anda harus mengonfigurasinya agar perangkat seluler dapat terhubung dengan FCM dan perangkat di jaringan Anda dapat menerima pesan. FCM biasanya menggunakan port 5228, namun terkadang menggunakan 5229 dan 5230.

Untuk koneksi keluar, FCM tidak memberikan IP khusus karena rentang IP kami terlalu sering berubah dan aturan firewall Anda mungkin sudah tidak berlaku, sehingga memengaruhi pengalaman pengguna Anda. Idealnya, Anda akan memberikan akses ke port 5228-5230 tanpa pembatasan IP. Namun, jika Anda harus memiliki pembatasan IP, Anda harus memberikan akses ke semua alamat IP dalam blok IPv4 dan IPv6 yang tercantum di ASN 15169 Google. Ini adalah daftar besar dan Anda harus memperbarui aturan setiap bulan. Masalah yang disebabkan karena pembatasan IP firewall biasanya menghilang dan timbul lagi serta sulit didiagnosis.

Port yang harus dibuka untuk pesan masuk:

  • 5228
  • 5229
  • 5230

Port untuk mengizinkan koneksi keluar:

Salah satunya (opsi #1 lebih diutamakan):

  1. Tidak ada pembatasan IP
  2. Semua alamat IP yang ada dalam blok IP yang tercantum di ASN 15169 Google. Jangan lupa untuk memperbaruinya minimal sebulan sekali.

Firewall Network Address Translation dan/atau Stateful Packet Inspection:

Jika jaringan Anda menerapkan Network Address Translation (NAT) atau Stateful Packet Inspection (SPI), terapkan waktu tunggu 30 menit atau lebih untuk koneksi kami melalui port 5228-5230. Dengan begitu, kami dapat menyediakan konektivitas yang andal sekaligus mengurangi konsumsi baterai perangkat seluler pengguna Anda.

Kredensial

Bergantung pada fitur FCM yang diterapkan, Anda mungkin membutuhkan kredensial berikut dari project Firebase Anda:

ID project ID unik untuk project Firebase Anda yang digunakan dalam permintaan ke endpoint HTTP FCM v1. Nilai ini tersedia di panel Setelan Firebase console.
Token pendaftaran ID yang dihasilkan oleh FCM SDK untuk setiap instance aplikasi klien. Diperlukan untuk pengiriman pesan 1 perangkat dan grup perangkat. Perhatikan bahwa token pendaftaran harus dirahasiakan.
ID Pengirim Nilai numerik unik yang dibuat ketika Anda membuat project Firebase, tersedia di tab Cloud Messaging pada panel Setelan Firebase console. ID pengirim digunakan untuk mengidentifikasi setiap pengirim yang dapat mengirim pesan ke aplikasi klien.
Token Akses Token OAuth 2.0 berumur pendek yang mengotorisasi permintaan ke HTTP v1 API. Token ini dikaitkan dengan akun layanan milik project Firebase Anda. Untuk membuat dan memutar token akses, ikuti langkah-langkah yang dijelaskan dalam Mengotorisasi Permintaan Kirim.
Kunci server (untuk protokol lama)

Kunci server yang memberikan otorisasi pada server aplikasi untuk mengakses layanan Google, termasuk mengirim pesan lewat protokol lama Firebase Cloud Messaging. Anda mendapatkan kunci server saat membuat project Firebase. Anda dapat melihatnya di tab Cloud Messaging pada panel Setelan Firebase console.

Penting: Jangan sertakan kunci server di mana pun pada kode klien. Selain itu, pastikan Anda menggunakan kunci server hanya untuk mengotorisasi server aplikasi. Kunci Android, iOS, dan browser ditolak oleh FCM.

Kirim masukan tentang...

Butuh bantuan? Kunjungi halaman dukungan kami.