Bu sayfa, Cloud Translation API ile çevrilmiştir.

Web Push Protokolü

Matt Gaunt

Bir kitaplığın push mesajlarını tetiklemek için nasıl kullanılabileceğini neler yapıyor?

Bu tür istekler doğru biçimde olduğundan emin olarak ağ istekleri gönderiyorlar. Bu ağ isteğini tanımlayan spesifikasyon Web Push Protokolü.

Sunucunuzdan bir push hizmetine push mesajı gönderme şeması

Bu bölümde, sunucunun uygulama ile kendini nasıl tanımlayabileceği sunucu anahtarları ve şifrelenmiş yük ile ilişkili verilerin nasıl gönderildiği hakkında bilgi verir.

Bu, web push'in hoş bir yönü değil ve şifreleme konusunda uzman değilim. Ancak bu kitaplıkların arka planda neler yaptığını bilmek yararlı olduğu için her bir parçayı inceleyelim.

Uygulama sunucusu anahtarları

Bir kullanıcıyı abone ettiğimizde bir applicationServerKey iletiyoruz. Bu anahtar push hizmetine iletilmiş ve abone olan uygulamanın kullanıcı aynı zamanda push mesajlarını tetikleyen uygulamadı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.)

Tüm bunlar tam olarak ne anlama geliyor ve tam olarak ne oluyor? İşte bunlar sizi başarıya götürecek adımlar uygulama sunucusu kimlik doğrulaması:

Uygulama sunucusu, bazı JSON bilgilerini özel uygulama anahtarıyla imzalar.
İmzalanan bu bilgiler, POST isteğinde başlık olarak push hizmetine gönderilir.
Push hizmeti, kendisinden aldığı depolanmış ortak anahtarı kullanır pushManager.subscribe(), alınan bilgileri imzalayıp imzalamadığını kontrol etmek için genel anahtarla ilgili özel anahtar. Hatırlatma: Ortak anahtar, abone olma çağrısına iletilen applicationServerKey değeridir.
İmzalanan bilgiler geçerliyse push hizmeti, mesajı görebilirsiniz.

Bu bilgi akışına örnek olarak aşağıdaki görseli inceleyebilirsiniz. (Genel ve özel anahtarları gösteren sol alttaki açıklamaya dikkat edin.)

Veri gönderilirken özel uygulama sunucusu anahtarının nasıl kullanıldığını gösteren resim
mesaj

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

JSON Web jetonu

JSON web jetonu (veya kısaca JWT), Üçüncü tarafa, alıcının doğrulayabileceği bir mesaj göndermek kim gönderdi?

Bir üçü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. Öğe imza geçerliyse JWT'nin, bununla eşleşen özel anahtar, bu nedenle beklenen gönderenden olmalıdır.

https://jwt.io/ adresinde birçok kitaplık bulunmaktadır. sizin yerinize imzalayabilir. Bunu yapmak için de yapabilir. Tamlık açısından, imzalı bir JWT'nin manuel olarak nasıl oluşturulacağına bakalım.

Web push ve imzalı JWT'ler

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

JSON Web'deki dizelerin resmi
Jeton

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

İlk dize, JWT'nin kendisiyle ilgili bilgilerdir ve hangi algoritmanın , imza oluşturmak için kullanıldı.

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

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

İkinci dize JWT Verileridir. Bu form, JWT'yi gönderen kişi hakkındaki bilgileri sağlar. ne kadar süre geçerli olacağı.

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" yani JWT'nin kim için olduğudur. Web için kitle, push hizmetidir. Bu nedenle, bunu push hizmet.

exp değeri, JWT'nin geçerlilik sonudur. Bu, meraklıların JWT'ye müdahale ederlerse yeniden kullanabilmeleri gerekir. Geçerlilik bitiş tarihi saniye uzunluğunda olmalıdır ve artık 24 saat olmamalıdır.

Node.js'de son kullanma tarihi şu şekilde ayarlanır:

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

Bu durumda, YouTube TV'yi kullanmamak için 24 saat yerine gönderen uygulama ve push hizmeti arasındaki saat farklarıyla ilgili sorunlar varsa.

Son olarak, sub değerinin bir URL veya mailto e-posta adresi olması gerekir. Böylece, bir push hizmetinin gönderene ulaşması gerektiğinde iletişim bilgilerini JWT'den alın. (Bu nedenle web push kitaplığının bir e-posta adresine ihtiyacı vardı).

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

İmza olan üçüncü dize, ilk iki dizeyi ("JWT Bilgileri" ve "JWT Verileri") "imzasız jeton" olarak adlandıracağımız bir nokta karakteriyle birleştirip imzalamanın sonucudur.

İmzalama işlemi, "imzasız jetonun" şifrelenmesini gerektirir ES256 kullanarak oluşturun. JWT spesifikasyonuna göre ES256, "P-256 eğrisini ve SHA-256 karma algoritmasını kullanan ECDSA"nın kısaltmasıdır. Web şifrelemesini 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, imzanın şifresini çözmek ve şifresi çözülmüş dizenin "imzasız jeton"la (yani JWT'deki ilk iki dize) aynı olduğundan emin olmak için genel uygulama sunucusu anahtarını kullanarak JWT'yi doğrulayabilir.

İmzalı JWT (yani üç dizenin de noktayla birleştirilmesi), web push hizmetine WebPush başlığı eklenmiş Authorization başlığı olarak gönderilir. Örneğin:

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

Web Push Protokolü ayrıca ortak uygulama sunucu anahtarının Crypto-Key üstbilgisinde, Başa p256ecdsa= eklendi.

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

Yük şifrelemesi

Şimdi de push mesajıyla bir yükü nasıl göndereceğimize bakalım. Böylece web uygulamamız bir push mesajı aldığında, aldığı verilere erişebilir.

Diğer push hizmetlerini kullananların sıklıkla sorduğu bir soru, web push yükü neden şifrelenmelidir? Yerleşik uygulamalarda push mesajları verileri düz metin olarak gönderebilir.

Web push'in avantajlarından biri, tüm push hizmetlerinin aynı API'yi (web push protokolü) kullanması nedeniyle geliştiricilerin push hizmetinin kim olduğuna dikkat etmemesidir. Doğru biçimde bir istek gönderebilir ve bir push mesajının gönderilmesini bekleyebiliriz. Bunun dezavantajı, geliştiricilerin güvenilir olmayan bir push hizmetine mesaj gönderebilmesidir. Ağırlığı şifreleyen bir itme 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.

Bir push mesajı yükü şifrelemeyle ilgili belirli adımlara bakmadan önce, şifreleme işlemi sırasında kullanılacak bazı teknikleri ele almamız gerekir. (Mat Scales'in itme konusundaki mükemmel makalesi için encryption.)

ECDH ve HKDF

Şifreleme sürecinde hem ECDH hem de HKDF'nin kullanılması, hem ECDH hem de HKDF'nin olduğunu varsayalım.

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

Bilgi paylaşmak isteyen iki kişiniz olduğunu varsayalım: Aylin ve Bora. Hem Aylin hem de Ali'nin kendi genel ve özel anahtarları vardır. Ayşe ve Bora, ortak anahtarlarını birbirleriyle paylaşır.

ECDH ile oluşturulan anahtarların faydalı özelliği, Aylin'in özel anahtarı ve İbrahim'in ortak anahtarını kullanarak 'X' gizli değerini oluşturun. Bob yapabilecekleri aynı şekilde, kendi özel anahtarını ve Ayşe'nin genel anahtarını bağımsız olarak aynı "X" değerini oluşturur. Bu, "X" oluşturur paylaşılan bir sır Aylin ve Bora'nın tek yapması gereken ortak anahtarlarını paylaşmaktı. Artık Ali ve Ayşe, aralarındaki mesajları şifrelemek ve şifresini çözmek için "X"i kullanabilir.

Bildiğim kadarıyla ECDH, bu "özelliğe" izin veren eğrilerin özelliklerini tanımlamaktadır. gizli bir 'X' gizli anahtarının oluşturulmasına neden olabilir.

Bu, ECDH'nin üst düzey bir açıklamasıdır. Daha fazla bilgi edinmek isterseniz bu videoya göz atmanızı öneririz.

Kod açısından, çoğu dil/platform bu anahtarları oluşturmayı kolaylaştırmak için kitaplıklarla birlikte gelir.

Düğümde şunları yaparız:

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

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

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

Wikipedia'da HKDF'nin kısa ve öz bir açıklaması vardır:

HKDF, zayıf anahtar materyallerini kriptografik olarak güçlü anahtar materyallerine dönüştüren HMAC tabanlı bir anahtar türetme işlevidir. Üretken yapay zeka, örnek olarak, Diffie Hellman, paylaşılan sırları önemli materyallere dönüştürerek şifreleme, bütünlük kontrolü veya kimlik doğrulamada kullanılmaya uygun olması gerekir.

Esasen, HKDF'nin özel olarak güvenli olmayan girdileri alıp daha güvenli hale getirmesi gerekir.

Bu şifrelemeyi tanımlayan spesifikasyon, karma oluşturma algoritmamız olarak SHA-256'nın kullanılmasını gerektirir ve web push'inde HKDF için elde edilen anahtarlar en fazla 256 bit (32 bayt) uzunluğunda olmalıdır.

Düğümde bu, ş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);
}

Mat Scale'in bu örnek kodla ilgili makalesine şapka ipucu.

Bu, ECDH ve HKDF'yi 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 güvenli hale getirmenin bir yoludur.

Bu, yükümüzün şifrelenmesi sırasında kullanılır. Şimdi, proje yöneticisi olarak şifrelendiğinden emin olun.

Girişler

Yükü olan bir kullanıcıya push mesajı göndermek istediğimizde ihtiyacımız olan üç giriş vardır:

Yükün kendisi.
PushSubscription kaynağındaki auth gizli anahtarı.
PushSubscription uygulamasındaki p256dh anahtarı.

auth ve p256dh değerlerinin bir PushSubscription kaynağından alındığını ancak bir abonelikte şu değerlere ihtiyacımız olacağını hatırlatmak isteriz:

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

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

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

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

Bu üç değer (auth, p256dh ve payload) giriş olarak gereklidir ve şifreleme işlemi; şifrelenmiş yük, takviye değer ve yalnızca verileri şifrelemek için kullanır.

Tuz

Güvenlik anahtarı, 16 bayt rastgele veri olmalıdır. NodeJS'de bir takviye değer 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. Bunu Node'da aşağıdaki gibi yaparız:

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

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

Bu anahtarlar "yerel anahtarlar" olarak adlandırılır. Yalnızca şifreleme amacıyla kullanılırlar ve hiçbir şey yapmanıza gerek yoktur.

Yük, kimlik doğrulama sırrı ve abonelik ortak anahtarı giriş olarak ve yeni oluşturulan ve yerel anahtar setimizin ardından, bazı şifreleme işlemleri yapmaya hazırız.

Paylaşılan gizli anahtar

İlk adım, aboneliğin ortak anahtarını ve yeni özel anahtarı (Ahmet ve İbrahim'in yaptığı ECDH açıklamasını hatırlıyor musunuz? Bu kadar).

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 tuş

Sözde Rastgele Anahtar (PRK), push aboneliğinin kimlik doğrulama kodunun birleşimidir gizli ve az önce oluşturduğumuz ortak bir sır.

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ısacası, net bir amacı yoktur ancak tarayıcılar gelen bir mesajın şifresini çözebilir ve beklenen içerik kodlamasını arayabilir. \0, Arabelleğin sonuna 0 değerine sahip bir bayt ekler. Bu çok fazla bayt bekleyecek olan iletinin şifresini çözen tarayıcıların (içerik kodlaması için, 0 değerinde bir bayt ve ardından şifrelenmiş veriler.

Sözde Rastgele Anahtarımız; kimlik doğrulamayı, paylaşılan sırrı ve bir parça kodlama bilgisini çalıştırır. (ör. kriptografik olarak daha güçlü hale getirme)

Bağlam

"Bağlam" şifrelemede daha sonra iki değeri hesaplamak için kullanılan bir bayt kümesidir tarayıcı. Bu temel olarak aboneliğin ortak anahtarını ve yerel ortak anahtarla aynı olmalıdır.

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 etikettir. Abonelik ortak anahtarındaki bayt sayısıdır. önce anahtarın kendisi, ardından yerel ortak anahtarın bayt sayısı ve ardından anahtar kendisi.

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

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

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

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

İlk olarak, tek seferlik rastgele sayı ve CEK için baytlar oluşturmamız gerekir. kodlama dizesi ve ardından az önce hesapladığımız bağlam arabelleği:

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, salt ve PRK'yı 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 bize tek seferlik rastgele sayı ve içerik şifreleme anahtarımızı verir.

Şifrelemeyi gerçekleştirme

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

İçerik şifreleme anahtarını kullanarak bir AES128 şifresi oluştururuz ilk kullanıma hazırlama vektörüdür.

Düğüm'de bu işlem aşağıdaki gibi yapılır:

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

Yükümüzü şifrelemeden önce, ne kadar dolgu istediğimizi tanımlamamız gerekir. yükünün önüne eklenir. Doldurma eklemek istememizin nedeni, dinleyicilerin yükü boyutuna göre iletilerin "türlerini" belirleyebilmesi riskini önlemesidir.

Ek dolgunun uzunluğunu belirtmek için iki bayt 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ü okumuş olursunuz. 5 baytlık dolgu eklediyseniz ilk iki baytın değeri 5 olur. Bu nedenle, tüketici beş bayt daha okur ve 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);

Daha sonra, dolgumuzu ve yükümizi bu şifre aracılığıyla çalıştırırız.

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!

Geriye kalan tek şey, bu yükün push hizmetine nasıl gönderileceğini belirlemektir.

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

Bu şifrelenmiş yükü push hizmetine göndermek için birkaç tane tanımlamamız gerekir. farklı başlıklar kullanır.

Şifreleme üstbilgisi

"Encryption" (Şifreleme) üstbilgisinde, yükün şifrelenmesi için kullanılan salt bulunmalıdır.

16 baytlık tuz, base64 URL güvenli kodlu olarak şifreleme başlığına eklenmelidir. Örneğin:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Şifreleme Anahtarı başlığı

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

Bu üst bilgi, şifreleme için kullanılan yerel ortak anahtarı paylaşmak için de kullanılır yüktü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ü, uzunluk ve kodlama üstbilgileri

Content-Length başlığı, şifrelenmiş yükteki bayt sayısıdır. "Content-Type" (İçerik Türü) ve "Content-Encoding" başlıklar sabit değerlerdir. Bu değer 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ün isteğimizin gövdesi olarak gönderilmesi gerekir. Content-Type değerinin application/octet-stream olarak ayarlandığını unutmayın. Bunun nedeni, şifrelenmiş yükün bayt akışı olarak gönderilir.

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ı?

JWT/uygulama sunucusu anahtarları için kullanılan üstbilgileri (ör. uygulamayı push hizmetiyle tanımlama) ve şifrelenmiş bir yükü göndermek için kullanılan üstbilgileri ele aldık.

Hizmetlerin, ileti gönderildi. Bu başlıklardan bazıları zorunlu, bazıları ise isteğe bağlıdır.

TTL başlığı

Zorunlu

TTL (veya geçerlilik süresi), saniye sayısını belirten bir tam sayıdır 24 saat boyunca push mesajınızın teslim edilir. TTL süresi dolduktan sonra mesaj, push hizmeti kuyruğundan kaldırılır ve teslim edilmez.

TTL: [Time to live in seconds]

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

Teknik olarak bir push hizmeti, isterse push mesajının TTL değerini düşürebilir. TTL başlığını inceleyerek bu durumun ne olduğunu anlayabilirsiniz. bir push hizmetinden gelen yanıttır.

Konu

İsteğe bağlı

Konular, beklemedeki mesajları yeni bir ileti gönderebilirsiniz.

Bu özellik, aynı anda birden fazla mesajın gönderilmesi ve kullanıcının yalnızca en güncel bilgileri görmesini istiyorsanız mesajı görebilirsiniz.

Öncelik

İsteğe bağlı

Aciliyet, push hizmetine bir iletinin kullanıcı için ne kadar önemli olduğunu belirtir. Bu kullanıcı cihazının pil ömrünü uzatmaya yardımcı olmak için push hizmeti tarafından yalnızca pil seviyesi düştüğünde önemli mesajlar için uyanıyor.

Başlık 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

Tüm bunların nasıl çalıştığıyla ilgili başka sorularınız olursa, kitaplıkların nasıl tetiklendiğini her zaman web-push-libs kuruluşunda push mesajları.

Şifrelenmiş bir yük ve yukarıdaki başlıkları elde ettikten sonra bir POST isteğinde bulunmanız yeterlidir PushSubscription içinde endpoint.

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

Push hizmetinden gelen yanıt

Push hizmetine istekte bulunduktan sonra durum kodunu kontrol etmeniz gerekir isteğin başarılı olup olmadığını gösterir. hakkında bilgi edindiniz.

Durum Kodu	Açıklama
201	Oluşturuldu. Push mesajı gönderme isteği alındı ve kabul edildi.
429	Çok fazla istek var. Uygulama sunucunuzun belirli bir hıza ulaştığı anlamına gelir konusunda daha fazla bilgi edinin. Push hizmetinde "Yeniden Dene" seçeneği bulunmalıdır. başlığını kullanarak istekte bulunabilirsiniz.
400	Geçersiz istek. Bu genellikle başlıklarınızdan birinin geçersiz olduğu anlamına gelir veya yanlış biçimlendirilmiş olabilir.
404	Bulunamadı. Bu, aboneliğin süresinin dolduğu ve kullanılamayacağını gösterir. Bu durumda, "PushSubscription"u silmeniz gerekir istemcinin kullanıcıya yeniden abone olmasını bekleyin.
410	Gitti. Abonelik artık geçerli değil ve uygulama sunucusundan kaldırılmalıdır. Bu, öğesini çağırarak yeniden oluşturabilirsiniz. "Pushsubscription" ile "unsubscribe()".
413	Yük boyutu çok büyük. Push hizmetinin gerektirdiği minimum boyut yükü destek 4.096 bayttır. (veya 4 KB).

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