{i>Web Push Protocol

Kita telah melihat bagaimana library dapat digunakan untuk memicu pesan push, tetapi apa sebenarnya yang dilakukan library ini?

Mereka membuat permintaan jaringan sambil memastikan permintaan tersebut memiliki format yang tepat. Spesifikasi yang menentukan permintaan jaringan ini adalah Web Push Protocol.

Diagram pengiriman pesan push dari server Anda ke layanan push

Bagian ini menguraikan cara server mengidentifikasi dirinya sendiri dengan kunci server aplikasi, dan cara pengiriman payload yang dienkripsi serta data terkait.

Ini bukan sisi web push yang menarik dan saya tidak ahli dalam enkripsi, tapi mari kita lihat setiap bagian karena akan sangat mudah untuk mengetahui apa yang dilakukan library ini.

Kunci server aplikasi

Saat pengguna membuat pengguna berlangganan, kita akan meneruskan applicationServerKey. Kunci ini diteruskan ke layanan push dan digunakan untuk memeriksa apakah aplikasi yang berlangganan pengguna juga merupakan aplikasi yang memicu pesan push.

Saat kita memicu pesan push, ada sekumpulan header yang kita kirim yang memungkinkan layanan push mengautentikasi aplikasi. (Hal ini ditentukan oleh spesifikasi VAPID.)

Apa arti dari semua ini dan apa yang sebenarnya terjadi? Berikut adalah langkah-langkah yang diambil untuk otentikasi server aplikasi:

  1. Server aplikasi menandatangani beberapa informasi JSON dengan kunci aplikasi pribadi-nya.
  2. Informasi bertanda tangan ini dikirim ke layanan push sebagai header dalam permintaan POST.
  3. Layanan push menggunakan kunci publik tersimpan yang diterima dari pushManager.subscribe() untuk memeriksa bahwa informasi yang diterima ditandatangani oleh kunci pribadi yang terkait dengan kunci publik. Ingat: Kunci publik adalah applicationServerKey yang diteruskan ke panggilan berlangganan.
  4. Jika informasi yang ditandatangani valid, layanan push akan mengirimkan pesan push kepada pengguna.

Contoh aliran informasi ini adalah sebagai berikut. (Perhatikan legenda di kiri bawah untuk menunjukkan kunci publik dan pribadi.)

Ilustrasi tentang cara kunci server aplikasi pribadi digunakan saat mengirim pesan

"Informasi bertanda tangan" yang ditambahkan ke header dalam permintaan adalah Token Web JSON.

Token web JSON

Token web JSON (atau disingkat JWT) adalah cara untuk mengirim pesan ke pihak ketiga sehingga penerima dapat memvalidasi pengirimnya.

Saat menerima pesan, pihak ketiga harus mendapatkan kunci publik pengirim dan menggunakannya untuk memvalidasi tanda tangan JWT. Jika tanda tangan valid, JWT harus ditandatangani dengan kunci pribadi yang cocok, sehingga harus berasal dari pengirim yang diharapkan.

Ada sejumlah library di https://jwt.io/ yang dapat melakukan penandatanganan untuk Anda dan sebaiknya Anda melakukannya sebisa mungkin. Agar lebih lengkap, mari lihat cara membuat JWT bertanda tangan secara manual.

Web push dan JWT bertanda tangan

JWT bertanda tangan hanyalah string, meskipun dapat dianggap sebagai tiga string yang digabungkan oleh titik.

Ilustrasi string dalam Token Web JSON

String pertama dan kedua (Info JWT dan data JWT) adalah bagian JSON yang telah dienkode base64, yang berarti dapat dibaca oleh publik.

String pertama adalah informasi tentang JWT itu sendiri, yang menunjukkan algoritme mana yang digunakan untuk membuat tanda tangan.

Info JWT untuk web push harus berisi informasi berikut:

{
  "typ": "JWT",
  "alg": "ES256"
}

String kedua adalah Data JWT. Ini memberikan informasi tentang pengirim JWT, siapa yang dituju dan berapa lama JWT valid.

Untuk web push, datanya akan memiliki format ini:

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:example@web-push-book.org"
}

Nilai aud adalah "audiens", yaitu untuk siapa JWT akan digunakan. Untuk push web, audiens adalah layanan push, jadi kita menetapkannya ke asal layanan push.

Nilai exp adalah masa berlaku JWT, yang mencegah pengintai menggunakan kembali JWT jika mencegatnya. Akhir masa berlaku adalah stempel waktu dalam detik dan tidak boleh lagi 24 jam.

Di Node.js, tanggal habis masa berlaku ditetapkan menggunakan:

Math.floor(Date.now() / 1000) + 12 * 60 * 60;

Waktu yang diperlukan adalah 12 jam, bukan 24 jam, untuk menghindari masalah dengan perbedaan jam antara aplikasi pengiriman dan layanan push.

Terakhir, nilai sub harus berupa URL atau alamat email mailto. Hal ini dimaksudkan agar jika layanan push perlu menghubungi pengirim, layanan tersebut dapat menemukan informasi kontak dari JWT. (Inilah alasan library web-push memerlukan alamat email).

Sama seperti Info JWT, Data JWT dienkode sebagai string base64 yang aman untuk URL.

String ketiga, tanda tangan, adalah hasil dari pengambilan dua string pertama (Info JWT dan Data JWT), gabungkan dengan karakter titik, yang akan kita sebut "token tanpa tanda tangan", dan penandatanganan.

Proses penandatanganan memerlukan enkripsi "token yang tidak ditandatangani" menggunakan ES256. Menurut spesifikasi JWT, ES256 adalah singkatan dari "ECDSA yang menggunakan kurva P-256 dan algoritma hash SHA-256". Dengan menggunakan kripto web, Anda dapat membuat tanda tangan seperti berikut:

// Utility function for UTF-8 encoding a string to an ArrayBuffer.
const utf8Encoder = new TextEncoder('utf-8');

// The unsigned token is the concatenation of the URL-safe base64 encoded
// header and body.
const unsignedToken = .....;

// Sign the |unsignedToken| using ES256 (SHA-256 over ECDSA).
const key = {
  kty: 'EC',
  crv: 'P-256',
  x: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(1, 33)),
  y: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(33, 65)),
  d: window.uint8ArrayToBase64Url(applicationServerKeys.privateKey),
};

// Sign the |unsignedToken| with the server's private key to generate
// the signature.
return crypto.subtle.importKey('jwk', key, {
  name: 'ECDSA', namedCurve: 'P-256',
}, true, ['sign'])
.then((key) => {
  return crypto.subtle.sign({
    name: 'ECDSA',
    hash: {
      name: 'SHA-256',
    },
  }, key, utf8Encoder.encode(unsignedToken));
})
.then((signature) => {
  console.log('Signature: ', signature);
});

Layanan push dapat memvalidasi JWT menggunakan kunci server aplikasi publik untuk mendekripsi tanda tangan dan memastikan string yang didekripsi sama dengan "token tanpa tanda tangan" (yaitu dua string pertama di JWT).

JWT yang ditandatangani (yaitu, ketiga string yang digabungkan dengan titik) dikirim ke layanan push web sebagai header Authorization dengan tambahan WebPush, seperti:

Authorization: 'WebPush [JWT Info].[JWT Data].[Signature]';

Web Push Protocol juga menyatakan bahwa kunci server aplikasi publik harus dikirim dalam header Crypto-Key sebagai string berenkode base64 keamanan URL dengan awalan p256ecdsa=.

Crypto-Key: p256ecdsa=[URL Safe Base64 Public Application Server Key]

Enkripsi Payload

Selanjutnya, mari kita lihat bagaimana kita dapat mengirim payload dengan pesan push sehingga saat aplikasi web kita menerima pesan push, aplikasi web itu dapat mengakses data yang diterimanya.

Pertanyaan umum yang muncul dari orang yang telah menggunakan layanan push lain adalah mengapa payload web push perlu dienkripsi? Dengan aplikasi native, pesan push dapat mengirim data sebagai teks biasa.

Bagian dari keindahan web push adalah bahwa karena semua layanan push menggunakan API yang sama (protokol push web), developer tidak perlu peduli siapa layanan push-nya. Kita dapat membuat permintaan dalam format yang tepat dan mengharapkan pesan push dikirim. Kelemahan dari ini adalah developer dapat mengirim pesan ke layanan push yang tidak dapat dipercaya. Dengan mengenkripsi payload, layanan push tidak dapat membaca data yang dikirim. Hanya browser yang dapat mendekripsikan informasi tersebut. Tindakan ini akan melindungi data pengguna.

Enkripsi payload didefinisikan dalam spesifikasi Message Encryption.

Sebelum membahas langkah-langkah khusus untuk mengenkripsi payload pesan push, kita perlu membahas beberapa teknik yang akan digunakan selama proses enkripsi. (Tips topi besar kepada Mat Scales untuk artikelnya yang sangat bagus tentang enkripsi push.)

ECDH dan HKDF

ECDH dan HKDF digunakan selama proses enkripsi dan menawarkan manfaat untuk tujuan enkripsi informasi.

ECDH: Pertukaran kunci Elliptic Curve Diffie-Hellman

Bayangkan Anda memiliki dua orang yang ingin berbagi informasi, Alia dan Bobi. Anisa dan Bob memiliki kunci publik dan pribadi mereka sendiri. Alice dan Bob berbagi kunci publik mereka satu sama lain.

Sifat berguna dari kunci yang dihasilkan dengan ECDH adalah bahwa Alice dapat menggunakan kunci pribadinya dan kunci publik Bob untuk membuat nilai secret 'X'. Bob dapat melakukan hal yang sama, dengan menggunakan kunci pribadinya dan kunci publik Alice untuk membuat nilai 'X' yang sama secara independen. Ini membuat 'X' menjadi rahasia bersama, sementara Alice dan Bob hanya perlu berbagi kunci publik mereka. Sekarang Bob dan Alice dapat menggunakan 'X' untuk mengenkripsi dan mendekripsi pesan di antara mereka.

ECDH, sejauh pengetahuan saya, mendefinisikan sifat kurva yang memungkinkan "fitur" pembuatan rahasia bersama 'X' ini.

Berikut adalah penjelasan mendetail tentang ECDH, jika Anda ingin mempelajari lebih lanjut, sebaiknya tonton video ini.

Dalam hal kode; sebagian besar bahasa / platform dilengkapi dengan library untuk memudahkan pembuatan kunci ini.

Di node, kita akan melakukan hal berikut:

const keyCurve = crypto.createECDH('prime256v1');
keyCurve.generateKeys();

const publicKey = keyCurve.getPublicKey();
const privateKey = keyCurve.getPrivateKey();

HKDF: Fungsi derivasi kunci berbasis HMAC

Wikipedia memiliki deskripsi ringkas tentang HKDF:

HKDF adalah fungsi perolehan kunci berbasis HMAC yang mengubah materi kunci yang lemah menjadi materi kunci yang kuat secara kriptografis. Enkripsi ini dapat digunakan, misalnya, untuk mengonversi Diffie Hellman dan bertukar rahasia bersama menjadi materi kunci yang dapat digunakan dalam enkripsi, pemeriksaan integritas, atau autentikasi.

Pada dasarnya, HKDF akan mengambil input yang tidak terlalu aman dan membuatnya lebih aman.

Spesifikasi yang menentukan enkripsi ini mengharuskan penggunaan SHA-256 sebagai algoritma hash kami dan kunci yang dihasilkan untuk HKDF dalam web push tidak boleh lebih dari 256 bit (32 byte).

Di node, hal ini dapat diterapkan seperti berikut:

// Simplified HKDF, returning keys up to 32 bytes long
function hkdf(salt, ikm, info, length) {
  // Extract
  const keyHmac = crypto.createHmac('sha256', salt);
  keyHmac.update(ikm);
  const key = keyHmac.digest();

  // Expand
  const infoHmac = crypto.createHmac('sha256', key);
  infoHmac.update(info);

  // A one byte long buffer containing only 0x01
  const ONE_BUFFER = new Buffer(1).fill(1);
  infoHmac.update(ONE_BUFFER);

  return infoHmac.digest().slice(0, length);
}

Tips topi untuk membaca artikel Mat Scale untuk kode contoh ini.

Hal ini hanya mencakup ECDH dan HKDF.

ECDH adalah cara yang aman untuk berbagi kunci publik dan menghasilkan rahasia bersama. HKDF adalah cara untuk mengambil materi yang tidak aman dan membuatnya aman.

Kunci ini akan digunakan selama enkripsi {i>payload<i} kita. Selanjutnya mari kita lihat apa yang kita ambil sebagai input dan bagaimana hal itu dienkripsi.

Input

Ketika kita ingin mengirim pesan push kepada pengguna dengan payload, ada tiga input yang kita butuhkan:

  1. Payload itu sendiri.
  2. Rahasia auth dari PushSubscription.
  3. Tombol p256dh dari PushSubscription.

Kita telah melihat nilai auth dan p256dh diambil dari PushSubscription, tetapi sebagai pengingat, mengingat langganan kita memerlukan nilai-nilai ini:

subscription.toJSON().keys.auth;
subscription.toJSON().keys.p256dh;

subscription.getKey('auth');
subscription.getKey('p256dh');

Nilai auth harus diperlakukan sebagai rahasia dan tidak dibagikan di luar aplikasi Anda.

Kunci p256dh adalah kunci publik, dan terkadang disebut sebagai kunci publik klien. Di sini kita akan menyebut p256dh sebagai kunci publik langganan. Kunci publik langganan dihasilkan oleh browser. Browser akan merahasiakan kunci pribadi ini dan menggunakannya untuk mendekripsi payload.

Ketiga nilai ini, auth, p256dh, dan payload diperlukan sebagai input, dan hasil dari proses enkripsi akan berupa payload terenkripsi, nilai salt, dan kunci publik yang digunakan hanya untuk mengenkripsi data.

Garam

Salt harus berukuran 16 byte data acak. Di NodeJS, kita akan melakukan hal berikut untuk membuat salt:

const salt = crypto.randomBytes(16);

Kunci Publik / Pribadi

Kunci publik dan pribadi harus dibuat menggunakan kurva eliptis P-256, yang akan kita lakukan di Node seperti berikut:

const localKeysCurve = crypto.createECDH('prime256v1');
localKeysCurve.generateKeys();

const localPublicKey = localKeysCurve.getPublicKey();
const localPrivateKey = localKeysCurve.getPrivateKey();

Kami menyebut kunci ini sebagai "kunci lokal". Kunci server digunakan hanya untuk enkripsi dan tidak ada hubungannya dengan kunci server aplikasi.

Dengan payload, rahasia autentikasi, dan kunci publik langganan sebagai input, serta dengan salt dan set kunci lokal yang baru dihasilkan, kita siap untuk benar-benar melakukan enkripsi.

Rahasia bersama

Langkah pertama adalah membuat rahasia bersama menggunakan kunci publik langganan dan kunci pribadi baru kita (ingatlah penjelasan ECDH dari Alice dan Bob? Mudah bukan).

const sharedSecret = localKeysCurve.computeSecret(
  subscription.keys.p256dh,
  'base64',
);

Hal ini digunakan pada langkah berikutnya untuk menghitung Kunci Acak Pseudo (PRK).

Kunci acak semu

Pseudo Random Key (PRK) adalah kombinasi dari rahasia autentikasi langganan push, dan rahasia bersama yang baru saja kita buat.

const authEncBuff = new Buffer('Content-Encoding: auth\0', 'utf8');
const prk = hkdf(subscription.keys.auth, sharedSecret, authEncBuff, 32);

Anda mungkin ingin tahu untuk apa string Content-Encoding: auth\0. Singkatnya, hal ini tidak memiliki tujuan yang jelas, meskipun browser dapat mendekripsi pesan masuk dan mencari encoding konten yang diharapkan. \0 menambahkan byte dengan nilai 0 ke akhir Buffer. Hal ini diperkirakan oleh browser yang mendekripsi pesan yang akan mengharapkan begitu banyak byte untuk encoding konten, diikuti byte dengan nilai 0, lalu data terenkripsi.

Kunci Acak Pseudo kami hanya menjalankan autentikasi, rahasia bersama, dan sedikit info encoding melalui HKDF (membuatnya lebih kuat secara kriptografis).

Konteks

"Konteks" adalah sekumpulan byte yang digunakan untuk menghitung dua nilai kemudian di browser enkripsi. Pada dasarnya, ini adalah array byte yang berisi kunci publik langganan dan kunci publik lokal.

const keyLabel = new Buffer('P-256\0', 'utf8');

// Convert subscription public key into a buffer.
const subscriptionPubKey = new Buffer(subscription.keys.p256dh, 'base64');

const subscriptionPubKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = subscriptionPubKey.length;

const localPublicKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = localPublicKey.length;

const contextBuffer = Buffer.concat([
  keyLabel,
  subscriptionPubKeyLength.buffer,
  subscriptionPubKey,
  localPublicKeyLength.buffer,
  localPublicKey,
]);

Buffering konteks akhir adalah label, jumlah byte dalam kunci publik langganan, diikuti dengan kunci itu sendiri, lalu jumlah byte untuk kunci publik lokal, diikuti dengan kunci itu sendiri.

Dengan nilai konteks ini, kita dapat menggunakannya dalam pembuatan nonce dan kunci enkripsi konten (CEK).

Kunci enkripsi konten dan nonce

Nonce adalah nilai yang mencegah serangan replay karena hanya boleh digunakan satu kali.

Kunci enkripsi konten (CEK) adalah kunci yang pada akhirnya akan digunakan untuk mengenkripsi payload kami.

Pertama, kita perlu membuat byte data untuk nonce dan CEK, yang hanya merupakan string encoding konten, diikuti dengan buffering konteks yang baru saja kita hitung:

const nonceEncBuffer = new Buffer('Content-Encoding: nonce\0', 'utf8');
const nonceInfo = Buffer.concat([nonceEncBuffer, contextBuffer]);

const cekEncBuffer = new Buffer('Content-Encoding: aesgcm\0');
const cekInfo = Buffer.concat([cekEncBuffer, contextBuffer]);

Informasi ini dijalankan melalui HKDF yang menggabungkan salt dan PRK dengan nonceInfo dan cekInfo:

// The nonce should be 12 bytes long
const nonce = hkdf(salt, prk, nonceInfo, 12);

// The CEK should be 16 bytes long
const contentEncryptionKey = hkdf(salt, prk, cekInfo, 16);

Ini memberi kita kunci enkripsi {i> nonce<i} dan konten.

Melakukan enkripsi

Setelah memiliki kunci enkripsi konten, kita dapat mengenkripsi payload.

Kami membuat penyandian AES128 menggunakan kunci enkripsi konten sebagai kuncinya, sedangkan nonce adalah vektor inisialisasi.

Di Node, hal ini dilakukan seperti berikut:

const cipher = crypto.createCipheriv(
  'id-aes128-GCM',
  contentEncryptionKey,
  nonce,
);

Sebelum mengenkripsi payload, kita perlu menentukan jumlah padding yang ingin ditambahkan ke bagian depan payload. Alasan kami menambahkan padding adalah karena mencegah risiko penyadap dapat menentukan "jenis" pesan berdasarkan ukuran payload.

Anda harus menambahkan dua byte padding untuk menunjukkan panjang padding tambahan.

Misalnya, jika tidak menambahkan padding, Anda akan memiliki dua byte dengan nilai 0, yaitu tidak ada padding, setelah dua byte ini Anda akan membaca payload. Jika Anda menambahkan 5 byte padding, dua byte pertama akan memiliki nilai 5, sehingga konsumen kemudian akan membaca lima byte tambahan dan kemudian mulai membaca payload.

const padding = new Buffer(2 + paddingLength);
// The buffer must be only zeros, except the length
padding.fill(0);
padding.writeUInt16BE(paddingLength, 0);

Kemudian kita menjalankan {i>padding<i} dan {i>payload<i} melalui penyandian ini.

const result = cipher.update(Buffer.concat(padding, payload));
cipher.final();

// Append the auth tag to the result -
// https://nodejs.org/api/crypto.html#crypto_cipher_getauthtag
const encryptedPayload = Buffer.concat([result, cipher.getAuthTag()]);

Kita sekarang memiliki payload terenkripsi. Hore!

Yang tersisa hanyalah menentukan bagaimana payload ini dikirim ke layanan push.

Header & isi payload terenkripsi

Untuk mengirim payload terenkripsi ini ke layanan push, kita perlu menentukan beberapa header berbeda dalam permintaan POST.

Header enkripsi

Header 'Enkripsi' harus berisi salt yang digunakan untuk mengenkripsi payload.

Salt 16 byte harus dienkode dengan aman dari URL base64 dan ditambahkan ke header Enkripsi, seperti berikut:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Header Crypto-Key

Kita melihat bahwa header Crypto-Key digunakan di bagian 'Kunci Server Aplikasi' untuk memuat kunci server aplikasi publik.

Header ini juga digunakan untuk membagikan kunci publik lokal yang digunakan untuk mengenkripsi payload.

Header yang dihasilkan akan terlihat seperti ini:

Crypto-Key: dh=[URL Safe Base64 Encoded Local Public Key String]; p256ecdsa=[URL Safe Base64 Encoded Public Application Server Key]

Header jenis konten, panjang & encoding

Header Content-Length adalah jumlah byte dalam payload yang dienkripsi. Header 'Content-Type' dan 'Content-Encoding' adalah nilai tetap. Hal ini ditampilkan di bawah ini.

Content-Length: [Number of Bytes in Encrypted Payload]
Content-Type: 'application/octet-stream'
Content-Encoding: 'aesgcm'

Setelah menetapkan header ini, kita perlu mengirim payload terenkripsi sebagai isi permintaan. Perhatikan bahwa Content-Type ditetapkan ke application/octet-stream. Ini karena payload terenkripsi harus dikirim sebagai aliran byte.

Di NodeJS, kita akan melakukannya seperti ini:

const pushRequest = https.request(httpsOptions, function(pushResponse) {
pushRequest.write(encryptedPayload);
pushRequest.end();

Header lainnya?

Kami telah membahas header yang digunakan untuk JWT / Kunci Server Aplikasi (yaitu cara mengidentifikasi aplikasi dengan layanan push) dan juga membahas header yang digunakan untuk mengirim payload yang dienkripsi.

Ada header tambahan yang digunakan layanan push untuk mengubah perilaku pesan terkirim. Beberapa header ini wajib ada, sementara yang lain bersifat opsional.

Header TTL

Wajib

TTL (atau waktu aktif) adalah bilangan bulat yang menentukan jumlah detik yang Anda inginkan untuk menampilkan pesan push pada layanan push sebelum dikirimkan. Ketika masa berlaku TTL berakhir, pesan akan dihapus dari antrean layanan push dan tidak akan dikirimkan.

TTL: [Time to live in seconds]

Jika Anda menyetel TTL dari nol, layanan push akan segera mencoba mengirimkan pesan, tetapi jika perangkat tidak dapat dijangkau, pesan Anda akan segera dihapus dari antrean layanan push.

Secara teknis, layanan push dapat mengurangi TTL pesan push jika diperlukan. Anda dapat mengetahui apakah hal ini terjadi dengan memeriksa header TTL dalam respons dari layanan push.

Topik

Opsional

Topik adalah string yang dapat digunakan untuk mengganti pesan yang tertunda dengan pesan baru jika memiliki nama topik yang cocok.

Hal ini berguna dalam skenario ketika beberapa pesan dikirim saat perangkat sedang offline, dan Anda benar-benar ingin pengguna melihat pesan terbaru hanya saat perangkat diaktifkan.

Urgensi

Opsional

Urgensi menunjukkan kepada layanan push seberapa penting pesan bagi pengguna. Ini dapat digunakan oleh layanan push untuk membantu menghemat masa pakai baterai perangkat pengguna dengan hanya bangun untuk pesan penting saat baterai lemah.

Nilai header ditentukan seperti yang ditunjukkan di bawah ini. Nilai defaultnya adalah normal.

Urgency: [very-low | low | normal | high]

Semuanya jadi satu

Jika ada pertanyaan lain tentang cara kerjanya, Anda selalu dapat melihat cara library memicu pesan push di web-push-libs org.

Setelah memiliki payload terenkripsi dan header di atas, Anda hanya perlu membuat permintaan POST ke endpoint dalam PushSubscription.

Jadi, apa yang kita lakukan dengan respons terhadap permintaan POST ini?

Respons dari layanan push

Setelah membuat permintaan ke layanan push, periksa kode status respons karena kode status akan memberi tahu Anda apakah permintaan berhasil atau tidak.

Kode Status Deskripsi
201 Dibuat. Permintaan untuk mengirim pesan push telah diterima dan diterima.
429 Terlalu banyak permintaan. Artinya, server aplikasi Anda telah mencapai batas kapasitas dengan layanan push. Layanan push harus menyertakan header 'Retry-After' untuk menunjukkan berapa lama sebelum permintaan lain dapat dibuat.
400 Permintaan tidak valid. Artinya, salah satu header Anda tidak valid atau tidak diformat dengan benar.
404 Tidak Ditemukan. Hal ini menunjukkan bahwa langganan telah habis masa berlakunya dan tidak dapat digunakan. Dalam hal ini, Anda harus menghapus `PushSubscription` dan menunggu klien untuk berlangganan kembali pengguna.
410 Hilang. Langganan tidak lagi valid dan harus dihapus dari server aplikasi. Ini dapat direproduksi dengan memanggil `unsubscribe()` pada `PushSubscription`.
413 Ukuran payload terlalu besar. Ukuran minimum payload yang harus didukung layanan push adalah 4096 byte (atau 4 kb).

Langkah berikutnya

Lab kode