Web Push Protokolü

Kitaplıkların push mesajlarını tetiklemek için nasıl kullanılabildiğini gördük. Peki bu kitaplıklar tam olarak ne yapıyor?

Bu isteklerin doğru biçimde olmasını sağlarken ağ istekleri gönderirler. Bu ağ isteğini tanımlayan spesifikasyon Web Push Protocol'dür.

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

Bu, web push'un güzel bir yanı değil ve şifreleme konusunda uzman olmasam da bu kitaplıkların arka planda neler yaptığını bilmek faydalı olacağından her bir parçayı inceleyelim.

Uygulama sunucusu anahtarları

Bir kullanıcıyı abone ettiğimizde applicationServerKey değerini iletiyoruz. Bu anahtar, push hizmetine iletilir ve kullanıcıyı abone eden uygulamanın, push mesajlarını tetikleyen uygulama olduğunu kontrol etmek için kullanılır.

Anlık bildirim tetiklediğimizde, anlık bildirim hizmetinin uygulamayı kimlik doğrulamasını sağlayan bir dizi üstbilgi göndeririz. (Bu, VAPID spesifikasyonu ile tanımlanır.)

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

1. Uygulama sunucusu, bazı JSON bilgilerini özel uygulama anahtarıyla imzalar.
2. Bu imzalı bilgiler, POST isteğinde başlık olarak push hizmetine gönderilir.
3. Push hizmeti, alınan bilgilerin ortak anahtarla ilişkili özel anahtarla imzalandığını kontrol etmek için pushManager.subscribe()'dan aldığı depolanmış ortak anahtarı kullanır. Unutmayın: Ortak anahtar, abone olma çağrısına iletilen applicationServerKey değeridir.
4. İmzalı bilgiler geçerliyse push hizmeti, push mesajını kullanıcıya gönderir.

Bu bilgi akışının bir örneğini aşağıda bulabilirsiniz. (Herkese açık ve özel anahtarları belirtmek için sol alttaki lejanda dikkat edin.)

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

JSON web jetonu

JSON web jetonu (kısaca JWT), alıcının kimin gönderdiğini doğrulayabileceği şekilde üçüncü tarafa mesaj göndermenin bir yoludur.

Üçüncü taraf bir ileti aldığında gönderenin ortak anahtarını alması ve JWT'nin imzasını doğrulamak için bu anahtarı kullanması gerekir. İmza geçerliyse JWT, eşleşen özel anahtarla imzalanmış olmalıdır. Bu nedenle, beklenen gönderenden gelmelidir.

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

Web push ve imzalı JWT'ler

İmzalı bir JWT, nokta ile birleştirilmiş üç dize olarak düşünülebilse de yalnızca bir dizedir.

Birinci ve ikinci dizeler (JWT bilgileri ve JWT verileri), Base64 ile kodlanmış JSON parçalarıdır. Bu nedenle, herkese açık olarak okunabilir.

İlk dize, JWT'nin kendisiyle ilgili bilgilerdir 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, kime yönelik olduğu ve ne kadar süreyle 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:example@web-push-book.org"
}

aud değeri, "kitle"dir. Diğer bir deyişle, JWT'nin kime yönelik olduğunu gösterir. Web push için kitle, push hizmetidir. Bu nedenle, kitleyi push hizmetinin kaynağı olarak ayarlarız.

exp değeri, JWT'nin geçerlilik süresidir. Bu değer, meraklıların JWT'yi yakaladıklarında yeniden kullanmasını engeller. 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 bu süre 24 saat değil 12 saattir.

Son olarak, sub değeri 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. (Bu nedenle web-push kitaplığı için e-posta adresi gerekiyordu.)

JWT verileri, JWT bilgileri gibi URL güvenli base64 dizesi olarak kodlanır.

Üçüncü dize olan imza, ilk iki dizeyi (JWT bilgileri ve JWT verileri) alıp nokta karakteriyle birleştirerek oluşturulur. Bu birleştirilmiş dizeye "imzalanmamış jeton" adını vereceğiz ve imzalayacağız.

İmzalama işlemi, "imzalanmamış jetonun" ES256 kullanılarak şifrelenmesini gerektirir. JWT spec'e göre ES256, "P-256 eğrisi ve SHA-256 karma algoritması kullanılarak ECDSA"nın kısaltmasıdır. Web kriptosu 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);
});

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

İmzalı JWT (yani noktalarla birleştirilmiş üç dize), web push hizmetine Authorization başlığı olarak WebPush önekli şekilde gönderilir. Örneğin:

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

Web Push Protokolü, herkese açık uygulama sunucusu anahtarının da Crypto-Key üstbilgisinde URL güvenli base64 kodlu bir dize olarak gönderilmesi gerektiğini belirtir. Bu dizenin başına p256ecdsa= eklenmelidir.

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

Yük Şifreleme

Ardından, web uygulamamız bir 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ıklıkla 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 güzelliği, tüm push hizmetlerinin aynı API'yi (web push protokolü) kullanması nedeniyle geliştiricilerin push hizmetinin kim olduğunu önemsememesi gerektiğidir. Doğru biçimde bir istekte bulunabilir ve bir 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 şifrelenmesi Message Encryption spec'te tanımlanır.

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

ECDH ve HKDF

Hem ECDH hem de HKDF, şifreleme işlemi boyunca kullanılır ve bilgilerin şifrelenmesi amacıyla 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 düşünelim. Ayşe ve Ali'nin hem genel hem de özel anahtarları vardır. Ayşe ve Ali birbirleriyle ortak anahtarlarını paylaşıyor.

ECDH ile oluşturulan anahtarların faydalı özelliği, Alice'in özel anahtarını ve Bob'un ortak anahtarını kullanarak "X" adlı gizli değeri oluşturabilmesidir. Barış da aynı şeyi yapabilir, özel anahtarını ve Ayşe'nin ortak anahtarını alarak aynı "X" değerini bağımsız olarak oluşturabilir. Bu durumda "X" paylaşılan gizli bilgiler haline gelir ve Alice ile Bob'un yalnızca ortak anahtarlarını paylaşmaları gerekir. Artık Ali ve Ayşe, aralarındaki mesajları şifrelemek ve mesajların şifresini çözmek için "X"i kullanabilir.

Bildiğim kadarıyla ECDH, ortak bir paylaşılan gizli bilgiler "X" oluşturma "özelliğine" izin veren eğrilerin özelliklerini tanımlar.

Bu, ECDH hakkında üst düzey bir açıklamadır. Daha fazla bilgi edinmek istiyorsanız ECDH'ye daha ayrıntılı bir genel bakış sunan videoyu izlemenizi öneririz.

Kod açısından; çoğu dil / platform, bu anahtarları kolayca oluşturmak için 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 almaktadır:

HKDF, zayıf anahtar materyalini kriptografik olarak güçlü anahtar materyaline dönüştüren, HMAC tabanlı bir anahtar türetme işlevidir. Örneğin, Diffie Hellman ile değiştirilen paylaşılan sırları şifreleme, bütünlük kontrolü veya kimlik doğrulama işlemlerinde kullanıma uygun anahtar materyaline dönüştürmek için kullanılabilir.

HKDF, temelde çok güvenli olmayan girişleri alıp daha güvenli hale getirir.

Bu şifrelemeyi tanımlayan spesifikasyon, karma algoritmamız olarak SHA-256'nın kullanılmasını gerektirir. Web push'taki HKDF için ortaya çıkan anahtarlar 256 bit'ten (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 kabaca kapsar.

ECDH, genel anahtarları paylaşmanın ve paylaşılan gizli bilgileri oluşturmanın güvenli bir yoludur. HKDF, güvenli olmayan materyali güvenli hale getirmenin bir yoludur.

Bu, yükümüzün şifrelenmesi sırasında kullanılır. Şimdi de hangi verileri girdi olarak aldığımıza ve bunların nasıl şifrelendiğine bakalım.

Girişler

Bir kullanıcıya yük içeren bir anlık ileti göndermek istediğimizde üç giriş yapmamız gerekir:

1. Yükün kendisi.
2. PushSubscription'nin auth sırrı.
3. PushSubscription içindeki p256dh anahtarı.

auth ve p256dh değerlerinin PushSubscription kaynağından alındığını gördük ancak abonelik için bu değerlere ihtiyacımız olduğunu hatırlatmak isteriz:

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

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

auth değeri gizli olarak kabul edilmeli ve uygulamanızın dışında paylaşılmamalıdır.

p256dh anahtarı, ortak anahtardır ve bazen istemci ortak anahtarı olarak da adlandırılır. Burada p256dh, abonelik ortak anahtarı olarak adlandırılacaktı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 sonucu ise şifrelenmiş yük, tuz değeri ve yalnızca verileri şifrelemek için kullanılan bir ortak anahtar olacaktır.

Salt

Bu takviye değeri 16 baytlık rastgele veri olmalıdır. NodeJS'te tuz oluşturmak için şunları yapardık:

const salt = crypto.randomBytes(16);

Herkese Açık / Ö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" diyeceğiz. Bunlar yalnızca şifreleme için kullanılır ve uygulama sunucusu anahtarlarıyla hiçbir ilgisi yoktur.

Giriş olarak yük, kimlik doğrulama gizli kodu ve abonelik ortak anahtarı ile yeni oluşturulmuş bir tuz ve yerel anahtar grubuyla birlikte, şifreleme işlemine başlamaya hazırız.

Paylaşılan gizli anahtar

İlk adım, abonelik ortak anahtarı ve yeni özel anahtarımızı kullanarak paylaşılan gizli bilgileri oluşturmaktır (Alice ve Bob ile ilgili ECDH açıklamasını hatırlıyor musunuz? İşte bu kadar basit).

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

Bu değer, 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 bilgilerin birleşimidir.

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

Content-Encoding: auth\0 dizisinin ne işe yaradığını merak ediyor olabilirsiniz. Kısacası, tarayıcılar gelen bir mesajın şifresini çözüp beklenen içerik kodlamasını arayabilse de net bir amacı yoktur. \0, arabelleğin sonuna 0 değerinde bir bayt ekler. Bu, mesajın şifresini çözen tarayıcılar tarafından beklenir. Tarayıcılar, içerik kodlaması için bu kadar çok bayt, ardından değeri 0 olan bir bayt ve ardından şifrelenmiş veriler bekler.

Sözde rastgele anahtarımız, kimlik doğrulama, paylaşılan gizli bilgiler ve bir kodlama bilgisini HKDF üzerinden geçirir (yani şifreleme açısından daha güçlü hale getirir).

Bağlam

"Bağlam", şifreleme tarayıcısında daha sonra iki değeri hesaplamak için kullanılan bir bayt kümesidir. Bu, 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, abonelik ortak anahtarındaki bayt sayısı etiketidir. Ardından anahtarın kendisi, yerel ortak anahtardaki bayt sayısı ve anahtarın kendisi gelir.

Bu bağlam değeriyle, nonce ve içerik şifreleme anahtarı (CEK) oluşturulurken kullanılabilir.

İçerik şifreleme anahtarı ve nonce

Nonce, yalnızca bir kez kullanılması gerektiğinden yeniden oynatma saldırılarını önleyen bir değerdir.

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

Öncelikle, nonce ve CEK için veri baytlarını oluşturmamız gerekir. Bu, basitçe içerik kodlama dizesi ve ardından az önce hesapladığımız bağlam arabelleğidir:

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, tuz ve PRK'yi nonceInfo ve cekInfo ile birleştiren HKDF üzerinden çalıştırılır:

// 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, nonce ve içerik şifreleme anahtarımızı verir.

Şifreleme işlemini gerçekleştirme

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

Anahtar olarak içerik şifreleme anahtarını, tek seferlik rastgele sayı olarak da başlatma vektörünü 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 eklememizin nedeni, dinleyenlerin yük boyutuna göre ileti "türlerini" belirleyebilme riskini önlemektir.

Ek dolgunun uzunluğunu belirtmek için iki bayt dolgu eklemeniz gerekir.

Örneğin, dolgu eklemediyseniz değeri 0 olan 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, 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ı üzerinden 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()]);

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

Geriye yalnızca bu yükün push hizmetine nasıl gönderileceğini belirlemek kalır.

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

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

Şifreleme üstbilgisi

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

16 baytlık tuz, Base64 URL güvenli kodlanmalı ve şifreleme üstbilgisine ş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çeren Crypto-Key başlığının kullanıldığını tespit ettik.

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 şu şekilde 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ü, uzunluğu ve kodlama üstbilgileri

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

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

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

NodeJS'de bu işlemi şu şekilde yapabiliriz:

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 başlıkları (ör. uygulamayı push hizmetiyle tanımlama) ve şifrelenmiş bir yük göndermek için kullanılan başlıkları ele aldık.

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

TTL üstbilgisi

Zorunlu

TTL (veya geçerlilik süresi), anlık iletinizin teslim edilmeden önce anlık iletme hizmetinde kalmasını istediğiniz saniye sayısını 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 teslim etmeye çalışır ancak cihaza ulaşılamazsa mesajınız push hizmeti kuyruğundan hemen çıkarılır.

Teknik olarak, bir push hizmeti isterse push mesajının TTL değerini azaltabilir. Bu durumun oluşup oluşmadığını, anlık bildirim hizmetinden gelen yanıttaki TTL üst bilgisini inceleyerek anlayabilirsiniz.

Konu

İsteğe bağlı

Konular, bekleyen iletileri yeni bir iletiyle değiştirmek için kullanılabilen ve eşleşen konu adlarına sahip olan dizelerdir.

Bu, bir cihaz çevrimdışıyken birden fazla mesaj 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, pil seviyesi düşükken yalnızca önemli mesajlar için uyandırarak kullanıcının cihazının pil ömrünü korumaya yardımcı olmak üzere anlık bildirim hizmeti tarafından kullanılabilir.

Başlık değeri aşağıda gösterildiği gibi tanımlanır. Varsayılan değer normal'dir.

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

Her şey bir arada

Tüm bunların nasıl çalıştığıyla ilgili başka sorularınız varsa kitaplıkların web-push-libs org'da nasıl anlık bildirimleri tetiklediğini her zaman görebilirsiniz.

Şifrelenmiş bir yükünüz ve yukarıdaki başlıklarınız olduğunda, endpoint adresine PushSubscription içinde 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 istekte bulunduktan sonra, isteğin başarılı olup olmadığını öğrenmek için yanıtın durum kodunu kontrol etmeniz gerekir.

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

Sonraki adımlar

• Web Push Bildirimlerine Genel Bakış
• Push'un İşleyiş Şekli
• Kullanıcıyı abone yapma
• İzin kullanıcı deneyimi
• Web Push Kitaplıklarıyla Mesaj Gönderme
• Web Push Protokolü
• Push Etkinliklerini İşleme
• Bildirim Gösterme
• Bildirim Davranışı
• Sık Karşılaşılan Bildirim Kalıpları
• Push Bildirimleri ile İlgili SSS
• Sık Karşılaşılan Sorunlar ve Hata Bildirme

Kod laboratuvarları

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