Web Push Protokolü

Matt Gaunt

Bir kitaplığın push mesajlarını tetiklemek için nasıl kullanılabileceğini gördük ancak bu kitaplıklar tam olarak ne yapıyor?

Ağ istekleri gönderirken bu isteklerin doğru biçimde olmasını sağlarlar. Bu ağ isteğini tanımlayan spesifikasyon, Web Push Protokolü'dür.

Bu bölümde, sunucunun uygulama sunucusu anahtarlarıyla kendisini nasıl tanımlayabileceği ve şifrelenmiş yük ile ilişkili verilerin nasıl gönderileceği açıklanmaktadır.

Bu, web push'un hoş bir tarafı değil ve şifreleme konusunda uzman değilim ancak bu kitaplıkların arka planda ne yaptığını bilmek faydalı olacağından her bir parçayı inceleyelim.

Uygulama sunucusu anahtarları

Bir kullanıcıyı abone yaptığımızda bir applicationServerKey iletiriz. Bu anahtar, push hizmetine iletilir ve kullanıcının abone olduğu uygulamanın, push mesajlarını tetikleyen uygulama olup olmadığını kontrol etmek için kullanılır.

Bir push mesajını tetiklediğimizde, push hizmetinin uygulamanın kimliğini doğrulamasına olanak tanıyan bir dizi üstbilgi göndeririz. (Bu, VAPID spesifikasyonu tarafından tanımlanır.)

Peki tüm bunlar ne anlama geliyor ve tam olarak ne oluyor? Uygulama sunucusu kimlik doğrulaması için şu adımlar uygulanır:

1. Uygulama sunucusu, bazı JSON bilgilerini özel uygulama anahtarı ile imzalar.
2. Bu imzalı bilgiler, POST isteğinde bir üstbilgi olarak push hizmetine gönderilir.
3. Push hizmeti, pushManager.subscribe() adresinden aldığı depolanmış ortak anahtarı kullanarak alınan bilgilerin ortak anahtarla ilgili özel anahtar tarafından imzalanıp imzalanmadığını kontrol eder. Unutmayın: Ortak anahtar, subscribe çağrısına iletilen applicationServerKey değeridir.
4. İmzalanan bilgiler geçerliyse push hizmeti, push mesajını kullanıcıya gönderir.

Bu bilgi akışının bir örneğini aşağıda görebilirsiniz. (Sol alttaki açıklama, ortak ve özel anahtarları gösterir.)

İstekteki bir başlığa eklenen "imzalı bilgiler" bir JSON Web Jetonu'dur.

JSON web jetonu

JSON web jetonu (veya kısaca JWT), alıcının göndereni doğrulayabileceği şekilde üçüncü tarafa mesaj gönderme yöntemidir.

Üçüncü taraflar bir mesaj aldığında, gönderenin ortak anahtarını alıp JWT imzasını doğrulamak için kullanmaları gerekir. İmza geçerliyse JWT, eşleşen özel anahtarla imzalanmış olmalıdır. Bu nedenle, beklenen gönderenden gelmelidir.

jwt.io/ adresinde imzalama işlemini sizin için gerçekleştirebilecek birçok kitaplık vardır. Mümkün olduğunda bu kitaplıkları kullanmanızı öneririz. Konuyu tamamlamak için imzalı JWT'nin manuel olarak nasıl oluşturulacağına bakalım.

Web push ve imzalı JWT'ler

İmzalı bir JWT yalnızca bir dizedir ancak noktalarla birleştirilmiş üç dize olarak da düşünülebilir.

İlk ve ikinci dizeler (JWT bilgileri ve JWT verileri), Base64 ile kodlanmış JSON parçalarıdır. Yani herkes tarafından okunabilir.

İlk dize, JWT'nin kendisiyle ilgili bilgileri içerir ve imzayı oluşturmak için hangi algoritmanın kullanıldığını gösterir.

Web push için JWT bilgileri aşağıdaki bilgileri içermelidir:

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

İkinci dize, JWT verileridir. Bu, JWT'nin göndereni, kimin için olduğu ve ne kadar süre geçerli olduğu hakkında bilgi sağlar.

Web push için veriler şu biçimde olur:

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:[e-mail]"
}

aud değeri, JWT'nin kime yönelik olduğunu belirten "kitle"dir. Web push için kitle, push hizmetidir. Bu nedenle, kitleyi push hizmetinin kaynağı olarak ayarlarız.

exp değeri, JWT'nin geçerlilik süresinin sona erme tarihidir. Bu, meraklıların JWT'yi ele geçirmeleri durumunda yeniden kullanmalarını önler. Geçerlilik süresi, saniye cinsinden bir zaman damgasıdır ve 24 saati aşmamalıdır.

Node.js'de geçerlilik bitiş tarihi şu şekilde ayarlanır:

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

Gönderen uygulama ile push hizmeti arasındaki saat farklarından kaynaklanan sorunları önlemek için 24 saat yerine 12 saat kullanılır.

Son olarak, sub değeri bir URL veya mailto e-posta adresi olmalıdır. Bu sayede, bir push hizmetinin gönderene ulaşması gerektiğinde JWT'den iletişim bilgilerini bulabilir. (Web push kitaplığının e-posta adresine ihtiyaç duymasının nedeni budur).

JWT Bilgileri gibi JWT Verileri de URL için güvenli base64 dizesi olarak kodlanır.

Üçüncü dize olan imza, ilk iki dizeyi (JWT Bilgisi ve JWT Verileri) alıp bunları "imzasız jeton" olarak adlandıracağımız bir nokta karakteriyle birleştirmenin ve imzalamanın sonucudur.

İmzalama işlemi, "imzasız jetonun" ES256 kullanılarak şifrelenmesini gerektirir. JWT spesifikasyonuna göre ES256, "P-256 eğrisi ve SHA-256 karma algoritması kullanan ECDSA"nın kısaltmasıdır. Web Crypto'yu kullanarak imzayı şu şekilde oluşturabilirsiniz:

// 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);
});

Push hizmeti, imzayı çözmek ve çözülen dizenin "imzasız jeton" (yani JWT'deki ilk iki dize) ile aynı olduğundan emin olmak için ortak uygulama sunucusu anahtarını kullanarak JWT'yi doğrulayabilir.

İmzalı JWT (yani noktalarla birleştirilmiş üç dize), web push hizmetine Authorization başlığı olarak, başına WebPush eklenerek şu şekilde gönderilir:

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

Web Push Protokolü, herkese açık uygulama sunucusu anahtarının Crypto-Key başlığında, başına p256ecdsa= eklenmiş URL için güvenli base64 kodlu dize olarak gönderilmesi gerektiğini de belirtir.

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

Yük şifrelemesi

Şimdi de web uygulamamız push mesajı aldığında, aldığı verilere erişebilmesi için push mesajıyla nasıl yük gönderebileceğimize bakalım.

Diğer push hizmetlerini kullananların sıkça sorduğu bir soru, web push yükünün neden şifrelenmesi gerektiğidir. Yerel uygulamalarda push mesajları, verileri düz metin olarak gönderebilir.

Web push'un en güzel yanlarından biri, tüm push hizmetlerinin aynı API'yi (web push protokolü) kullanmasıdır. Bu sayede geliştiricilerin push hizmetinin kim olduğunu önemsemesi gerekmez. Doğru biçimde istekte bulunabilir ve push mesajının gönderilmesini bekleyebiliriz. Bunun dezavantajı, geliştiricilerin güvenilir olmayan bir push hizmetine mesaj gönderebilmesidir. Yük şifrelendiğinde push hizmeti gönderilen verileri okuyamaz. Bilgilerin şifresini yalnızca tarayıcı çözebilir. Bu sayede kullanıcının verileri korunur.

Yükün şifrelemesi, Mesaj Şifreleme spesifikasyonunda tanımlanır.

Push mesajı yükünü şifrelemeyle ilgili adımlara bakmadan önce, şifreleme işlemi sırasında kullanılacak bazı teknikleri ele almamız gerekir. (Push şifreleme hakkındaki mükemmel makalesi için Mat Scales'e çok teşekkür ederiz.)

ECDH ve HKDF

Hem ECDH hem de HKDF, şifreleme süreci boyunca kullanılır ve bilgileri şifreleme konusunda avantajlar sunar.

ECDH: Eliptik Eğri Diffie-Hellman anahtar değişimi

Ayşe ve Ali adında iki kişinin bilgi paylaşmak istediğini varsayalım. Ayşe ve Ali'nin kendi ortak ve özel anahtarları vardır. Ayşe ve Ali, ortak anahtarlarını birbirleriyle paylaşır.

ECDH ile oluşturulan anahtarların kullanışlı özelliği, Alice'in kendi özel anahtarını ve Bob'un ortak anahtarını kullanarak "X" gizli değerini oluşturabilmesidir. Bob da aynı şeyi yapabilir. Özel anahtarını ve Alice'in ortak anahtarını kullanarak aynı "X" değerini bağımsız olarak oluşturabilir. Böylece "X" paylaşılan bir gizli anahtar olur ve Aylin ile Bora'nın yalnızca ortak anahtarlarını paylaşması gerekir. Artık Ali ve Ayşe, aralarındaki mesajları şifrelemek ve şifrelerini çözmek için "X"i kullanabilir.

Bildiğim kadarıyla ECDH, paylaşılan bir gizli "X" oluşturma "özelliğini" sağlayan eğrilerin özelliklerini tanımlar.

Bu, ECDH'nin genel bir açıklamasıdır. Daha fazla bilgi edinmek isterseniz daha ayrıntılı bir ECDH genel bakış videosuna göz atmanızı öneririm.

Kod açısından; çoğu dil/platform, bu anahtarların oluşturulmasını kolaylaştıran kitaplıklarla birlikte gelir.

Node'da şunları yaparız:

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

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

HKDF: HMAC tabanlı anahtar türetme işlevi

Wikipedia'da HKDF ile ilgili kısa bir açıklama yer alır:

HKDF, zayıf anahtar materyallerini kriptografik olarak güçlü anahtar materyallerine dönüştüren HMAC tabanlı bir anahtar türetme işlevidir. Örneğin, Diffie Hellman tarafından paylaşılan gizli anahtarları şifreleme, bütünlük kontrolü veya kimlik doğrulama için uygun anahtar materyaline dönüştürmek amacıyla kullanılabilir.

HKDF, temelde güvenli olmayan girişleri daha güvenli hale getirir.

Bu şifrelemeyi tanımlayan spesifikasyon, karma algoritması olarak SHA-256'nın kullanılmasını gerektirir ve web push'ta HKDF için elde edilen anahtarlar 256 bitten (32 bayt) uzun olmamalıdır.

Node'da bu işlem şu şekilde uygulanabilir:

// 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);
}

Bu örnek kod için Mat Scale'in makalesine teşekkür ederiz.

Bu, ECDH ve HKDF'yi genel olarak kapsar.

ECDH, ortak anahtarları paylaşmanın ve paylaşılan bir gizli anahtar oluşturmanın güvenli bir yoludur. HKDF, güvenli olmayan materyalleri alıp güvenli hale getirmenin bir yoludur.

Bu anahtar, yükümüzün şifrelenmesi sırasında kullanılır. Şimdi de giriş olarak ne aldığımıza ve bunun nasıl şifrelendiğine bakalım.

Girişler

Bir kullanıcıya yük içeren bir push mesajı göndermek istediğimizde üç girişe ihtiyacımız vardır:

1. Yükün kendisi.
2. PushSubscription uygulamasından auth gizli anahtarı.
3. PushSubscription anahtarından p256dh anahtarı.

auth ve p256dh değerlerinin PushSubscription üzerinden alındığını gördük. Ancak bir abonelik için gereken değerleri kısaca hatırlatmak isteriz:

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

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

auth değeri gizli olarak ele alınmalı ve uygulamanızın dışında paylaşılmamalıdır.

p256dh anahtarı, bazen istemci ortak anahtarı olarak da adlandırılan bir ortak anahtardır. Burada p256dh, abonelik ortak anahtarı olarak adlandırılır. Abonelik ortak anahtarı tarayıcı tarafından oluşturulur. Tarayıcı, özel anahtarı gizli tutar ve yükün şifresini çözmek için kullanır.

auth, p256dh ve payload değerleri giriş olarak gereklidir. Şifreleme işleminin sonucunda şifrelenmiş yük, bir takviye değer ve yalnızca verileri şifrelemek için kullanılan bir ortak anahtar elde edilir.

Salt

Salt, 16 baytlık rastgele veri olmalıdır. NodeJS'de, salt oluşturmak için aşağıdakileri yaparız:

const salt = crypto.randomBytes(16);

Genel/Özel Anahtarlar

Ortak ve özel anahtarlar, P-256 eliptik eğrisi kullanılarak oluşturulmalıdır. Node'da bunu şu şekilde yaparız:

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

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

Bu anahtarlara "yerel anahtarlar" denir. Yalnızca şifreleme için kullanılırlar ve uygulama sunucusu anahtarlarıyla hiçbir ilgileri yoktur.

Yük, kimlik doğrulama gizli anahtarı ve abonelik ortak anahtarını giriş olarak kullanıp yeni oluşturulan bir salt ve yerel anahtar grubuyla şifreleme yapmaya hazırız.

Paylaşılan gizli anahtar

İlk adım, abonelik ortak anahtarını ve yeni özel anahtarımızı kullanarak paylaşılan bir gizli anahtar oluşturmaktır (Alice ve Bob ile ECDH açıklamasını hatırlayın). İşte böyle).

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

Bu, bir sonraki adımda Sözde Rastgele Anahtar'ı (PRK) hesaplamak için kullanılır.

Sözde rastgele anahtar

Sözde Rastgele Anahtar (PRK), push aboneliğinin kimlik doğrulama gizli anahtarı ile az önce oluşturduğumuz paylaşılan gizli anahtarın birleşimidir.

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

Content-Encoding: auth\0 dizesinin ne işe yaradığını merak ediyor olabilirsiniz. Kısaca, tarayıcılar gelen bir mesajın şifresini çözüp beklenen içerik kodlamasını arayabilse de bunun net bir amacı yoktur. \0, Buffer'ın sonuna 0 değerine sahip bir bayt ekler. Bu, mesajın şifresini çözen tarayıcılar tarafından beklenir. Tarayıcılar, içerik kodlaması için belirli sayıda bayt, ardından değeri 0 olan bir bayt ve son olarak şifrelenmiş verileri bekler.

Sözde Rastgele Anahtarımız, yetkilendirme, paylaşılan gizli anahtar ve bir kodlama bilgisi parçasını HKDF aracılığıyla çalıştırır (yani şifreleme açısından daha güçlü hale getirir).

Bağlam

"Bağlam", daha sonra şifreleme tarayıcısında iki değeri hesaplamak için kullanılan bir bayt kümesidir. Bu, temelde abonelik ortak anahtarını ve yerel ortak anahtarı içeren bir bayt dizisidir.

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,
]);

Son bağlam arabelleği bir etiket, abonelik ortak anahtarındaki bayt sayısı, ardından anahtarın kendisi, ardından yerel ortak anahtarın bayt sayısı ve anahtarın kendisidir.

Bu bağlam değerini, tek seferlik rastgele sayı ve içerik şifreleme anahtarı (CEK) oluşturmak için kullanabiliriz.

İçerik şifreleme anahtarı ve tek seferlik rastgele sayı

Tek seferlik rastgele sayı, yalnızca bir kez kullanılması gerektiğinden tekrar saldırılarını önleyen bir değerdir.

İçerik şifreleme anahtarı (CEK), yükümüzü şifrelemek için kullanılacak anahtardır.

Öncelikle tek seferlik rastgele sayı ve CEK için veri baytlarını oluşturmamız gerekir. Bu, içerik kodlama dizesinin ardından az önce hesapladığımız bağlam arabelleğinin eklenmesiyle elde edilir:

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]);

Bu bilgiler, HKDF aracılığıyla çalıştırılarak salt ve PRK, nonceInfo ve cekInfo ile birleştirilir:

// 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);

Bu işlem sonucunda tek seferlik rastgele sayı ve içerik şifreleme anahtarı elde edilir.

Şifreleme işlemini gerçekleştirme

İçerik şifreleme anahtarımızı aldığımıza göre yükü şifreleyebiliriz.

İçerik şifreleme anahtarını anahtar, tek seferlik rastgele sayıyı ise başlatma vektörü olarak kullanarak bir AES128 şifresi oluştururuz.

Node'da bu işlem şu şekilde yapılır:

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

Yükümüzü şifrelemeden önce yükün önüne ne kadar dolgu eklemek istediğimizi tanımlamamız gerekir. Dolgu eklemek istememizin nedeni, gizlice dinleyenlerin yük boyutuna göre mesajların "türlerini" belirleme riskini önlemesidir.

Ek dolguların uzunluğunu belirtmek için iki baytlık dolgu eklemeniz gerekir.

Örneğin, dolgu eklemediyseniz 0 değerine sahip iki baytınız olur.Yani dolgu yoktur. Bu iki bayttan sonra yükü okursunuz. 5 bayt dolgu eklediyseniz ilk iki baytın değeri 5 olur. Böylece tüketici, ek beş bayt daha okur ve ardından yükü okumaya başlar.

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

Ardından, dolgu ve yükümüzü bu şifreleme algoritmasından geçiririz.

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()]);

Artık şifrelenmiş yükümüz var. Yaşasın!

Şimdi bu yükün push hizmetine nasıl gönderileceğini belirlemeniz gerekir.

Şifrelenmiş yük üstbilgileri ve gövdesi

Bu şifrelenmiş yükü push hizmetine göndermek için POST isteğimizde birkaç farklı başlık tanımlamamız gerekir.

Şifreleme üstbilgisi

"Şifreleme" başlığı, yükü şifrelemek için kullanılan salt değerini içermelidir.

16 baytlık salt, base64 URL için güvenli olarak kodlanmalı ve şifreleme başlığına şu şekilde eklenmelidir:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Crypto-Key üstbilgisi

"Uygulama Sunucusu Anahtarları" bölümünde, ortak uygulama sunucusu anahtarını içermek için Crypto-Key başlığının kullanıldığını gördük.

Bu başlık, yükü şifrelemek için kullanılan yerel ortak anahtarı paylaşmak için de kullanılır.

Elde edilen başlık aşağıdaki gibi görünür:

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

İçerik türü, uzunluk ve kodlama üstbilgileri

Content-Length başlığı, şifrelenmiş yükteki bayt sayısıdır. "Content-Type" ve "Content-Encoding" başlıkları sabit değerlerdir. Bu durum aşağıda gösterilmiştir.

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

Bu üstbilgiler ayarlandıktan sonra, şifrelenmiş yükü isteğimizin gövdesi olarak göndermemiz gerekir. Content-Type değerinin application/octet-stream olarak ayarlandığına dikkat edin. Bunun nedeni, şifrelenmiş yükün bayt akışı olarak gönderilmesi gerektiğidir.

NodeJS'de bunu şu şekilde yaparız:

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

Daha fazla başlık mı istiyorsunuz?

JWT/Uygulama Sunucusu Anahtarları için kullanılan üstbilgileri (yani uygulamanın push hizmetiyle nasıl tanımlanacağını) ve şifrelenmiş bir yükü göndermek için kullanılan üstbilgileri ele aldık.

Push hizmetlerinin, gönderilen mesajların davranışını değiştirmek için kullandığı ek başlıklar vardır. Bu başlıklardan bazıları zorunlu, bazıları ise isteğe bağlıdır.

TTL üstbilgisi

Zorunlu

TTL (veya geçerlilik süresi), push mesajınızın teslim edilmeden önce push hizmetinde ne kadar süre (saniye cinsinden) kalmasını istediğinizi belirten bir tam sayıdır. TTL süresi dolduğunda mesaj, push hizmeti sırasından kaldırılır ve teslim edilmez.

TTL: [Time to live in seconds]

TTL değerini sıfır olarak ayarlarsanız push hizmeti mesajı hemen iletmeye çalışır ancak cihaza ulaşılamazsa mesajınız push hizmeti sırasından hemen çıkarılır.

Teknik olarak, push hizmeti isterse push mesajının TTL değerini düşürebilir. Bunun gerçekleşip gerçekleşmediğini, push hizmetinden gelen yanıttaki TTL başlığını inceleyerek anlayabilirsiniz.

Konu

İsteğe bağlı

Konular, eşleşen konu adlarına sahip olmaları durumunda bekleyen mesajları yeni bir mesajla değiştirmek için kullanılabilen dizelerdir.

Bu, cihaz çevrimdışıyken birden fazla mesajın gönderildiği ve cihaz açıldığında kullanıcının yalnızca en son mesajı görmesini istediğiniz senaryolarda kullanışlıdır.

Öncelik

İsteğe bağlı

Aciliyet, push hizmetine bir mesajın kullanıcı için ne kadar önemli olduğunu gösterir. Bu, push hizmeti tarafından, pil seviyesi düşükken yalnızca önemli mesajlar için uyandırılarak kullanıcının cihazının pil ömrünü korumaya yardımcı olmak için kullanılabilir.

Üstbilgi değeri aşağıda gösterildiği gibi tanımlanır. Varsayılan değer: normal.

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

Her şey bir arada

Bu sürecin işleyişiyle ilgili başka sorularınız varsa kitaplıkların push mesajlarını nasıl tetiklediğini web-push-libs kuruluşunda inceleyebilirsiniz.

Şifrelenmiş bir yükünüz ve yukarıdaki başlıklarınız olduğunda, PushSubscription içinde endpoint adresine bir POST isteği göndermeniz yeterlidir.

Peki bu POST isteğine verilen yanıtla ne yapacağız?

Push hizmetinden yanıt

Bir push hizmetine istek gönderdikten sonra, isteğin başarılı olup olmadığını anlamak için yanıtın durum kodunu kontrol etmeniz gerekir.

Durum Kodu	Açıklama
201	Oluşturuldu. Push mesajı gönderme isteği alındı ve kabul edildi.
429	Çok fazla istek var. Bu, uygulama sunucunuzun bir push hizmetiyle sıklık sınırlamasına ulaştığı anlamına gelir. Push hizmeti, başka bir isteğin ne kadar süre sonra yapılabileceğini belirtmek için "Retry-After" başlığı içermelidir.
400	Geçersiz istek. Bu genellikle başlıklarınızdan birinin geçersiz veya yanlış biçimlendirilmiş olduğu anlamına gelir.
404	Bulunamadı. Bu, aboneliğin süresinin dolduğunu ve kullanılamayacağını gösterir. Bu durumda, `PushSubscription`ı silmeniz ve istemcinin kullanıcıyı yeniden abone yapmasını beklemeniz gerekir.
410	Yoktur. Abonelik artık geçerli değildir ve uygulama sunucusundan kaldırılmalıdır. Bu durum, bir `PushSubscription` üzerinde `unsubscribe()` çağrılarak yeniden oluşturulabilir.
413	Yük boyutu çok büyük. Bir push hizmetinin desteklemesi gereken minimum yük boyutu 4.096 bayttır (veya 4 KB).

HTTP durum kodları hakkında daha fazla bilgi için Web Push standardını (RFC8030) da okuyabilirsiniz.

Sonraki adımlar

• Web Push Bildirimlerine Genel Bakış
• Push'un İşleyiş Şekli
• Kullanıcı abone etme
• İzin kullanıcı deneyimi
• Web Push kitaplıklarıyla mesaj gönderme
• Web Push Protokolü
• Push etkinliklerini işleme
• Bildirim gösterme
• Bildirim Davranışı
• Yaygın Bildirim Kalıpları
• Push bildirimleri ile ilgili SSS
• Sık Karşılaşılan Sorunlar ve Hata Bildirme

Kod laboratuvarları

• Push bildirimi istemcisi oluşturma
• Push bildirimi sunucusu oluşturma