Ta strona została przetłumaczona przez Cloud Translation API.

Protokół Web Push Protocol

Matt Gaunt

Omówiliśmy, jak za pomocą biblioteki wyzwalać wiadomości push, czy dokładnie te biblioteki

Wysyłają żądania sieciowe, a jednocześnie dbają o to, aby były mają właściwy format. Specyfikacja, która definiuje to żądanie sieciowe, to protokół Web Push.

Schemat wysyłania wiadomości push z serwera do trybu push
usługa

Ta sekcja zawiera omówienie sposobu, w jaki serwer może zidentyfikować się z aplikacją kluczy serwera oraz sposobu wysyłania zaszyfrowanego ładunku i powiązanych danych.

To nie jest piękna strona Web push, a nie znam się na szyfrowaniu, ale przyjrzyjmy się temu bliżej. bo dobrze jest wiedzieć, jak te biblioteki robią.

Klucze serwera aplikacji

Gdy rejestrujemy użytkownika, przekazujemy applicationServerKey. Ten klucz jest przekazywany usłudze przesyłania wiadomości push i służy do sprawdzania, czy aplikacja, do której użytkownik się zapisał, jest też aplikacją, która uruchamia wiadomości push.

Wywołując wiadomość push, wysyłamy zestaw nagłówków, zezwala usłudze push na uwierzytelnianie aplikacji. (jest to zdefiniowane w specyfikacji VAPID).

Co to wszystko oznacza i co się dokładnie dzieje? Oto czynności podejmowane w ramach uwierzytelniania serwera aplikacji:

Serwer aplikacji podpisuje niektóre informacje JSON za pomocą klucza aplikacji prywatnej.
Te podpisane informacje są wysyłane do usługi push jako nagłówek w żądaniu POST.
Usługa push używa zapisanego klucza publicznego, z którego otrzymano pushManager.subscribe(), aby sprawdzić, czy odebrane informacje zostały podpisane przez z kluczem publicznym. Pamiętaj: klucz publiczny to applicationServerKey przekazany do wywołania subscribe.
Jeśli podpisane informacje są prawidłowe, usługa push wysyła wiadomość push do użytkownika.

Poniżej znajdziesz przykład przepływu informacji. (zwróć uwagę na legendę w lewym dolnym rogu, która wskazuje klucze publiczne i prywatne).

Grafika przedstawiająca sposób użycia klucza prywatnego serwera aplikacji podczas wysyłania
wiadomość

„Podpisane informacje” dodane do nagłówka w żądaniu to token internetowy JSON.

Token internetowy JSON

Token sieciowy JSON (JWT) to sposób wysyłanie wiadomości do osoby trzeciej, aby odbiorca mógł ją zweryfikować; kto je wysłał.

Gdy inna firma otrzyma wiadomość, musi uzyskać informacje o nadawcy. klucz publiczny i użyj go do weryfikacji podpisu tokena JWT. Jeśli podpis jest prawidłowy, token JWT musi być podpisany odpowiednim kluczem prywatnym, więc musi pochodzić od oczekiwanego nadawcy.

Na stronie https://jwt.io/ znajdziesz biblioteki, które może wykonać za Ciebie podpis. Zalecamy zrobić to tam, tak. Dla pewności zobaczmy, jak ręcznie utworzyć podpisany token JWT.

Web push i podpisane tokeny JWT

Podpisany token JWT to tylko ciąg znaków, ale można go traktować jako 3 ciągi połączone kropkami.

Ilustracja przedstawiająca ciągi tekstowe w tokenie internetowym JSON

Pierwszy i drugi ciąg znaków (informacje JWT i dane JWT) to fragmenty danych JSON zakodowane w formacie base64, co oznacza, że są one dostępne do odczytu publicznie.

Pierwszy ciąg to informacje o tokenie JWT, który wskazuje, który algorytm posłużył do utworzenia podpisu.

W przypadku web push informacje JWT muszą zawierać te informacje:

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

Drugi ciąg to dane JWT. Zawiera informacje o nadawcy JWT, który przeznaczenia i jak długo jest ważny.

W przypadku push z sieci dane mają taki format:

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

Wartość aud określa „odbiorcy”, czyli dla kogo jest przeznaczony token JWT. W przypadku internetu naciśnij jest usługą push, więc ustawiamy ją na pochodzenie elementu push. usługi.

Wartość exp to data wygaśnięcia tokena JWT. Zapobiega to ponownemu wykorzystaniu tokena JWT przez szpiegów, jeśli zostanie on przechwycony. Czas wygaśnięcia to sygnatura czasowa w sekundach, która nie może być dłuższa niż 24 godziny.

W Node.js data ważności jest ustawiana za pomocą:

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

Jest to 12 godzin, a nie 24 godziny, aby uniknąć wszelkie problemy z różnicami zegara między aplikacją wysyłającą a usługą push.

Na koniec wartością sub musi być URL lub mailto. Dzięki temu, jeśli usługa push będzie musiała skontaktować się z nadawcą, będzie mogła znaleźć informacje kontaktowe w tokenie JWT. (dlatego biblioteka web-push wymagała adresu e-mail).

Podobnie jak informacje JWT, dane JWT są zakodowane jako bezpieczny adres URL w base64 ciągu znaków.

Trzeci ciąg znaków, czyli podpis, jest wynikiem połączenia dwóch pierwszych ciągów znaków (informacji JWT i danych JWT) za pomocą znaku kropki. Nazywamy go „niepodpisanym tokenem”.

Proces podpisywania wymaga zaszyfrowania „niepodpisanego tokena” przy użyciu standardu ES256. Zgodnie ze specyfikacją JWT ES256 to skrót od „ECDSA z krzywą P-256 i algorytmem haszującym SHA-256”. Za pomocą szyfrowania internetowego możesz utworzyć podpis w ten sposób:

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

Usługa push może zweryfikować token JWT za pomocą klucza publicznego serwera aplikacji aby odszyfrować podpis i upewnić się, że odszyfrowany ciąg jest taki sam jako „niepodpisany token” (tzn. pierwsze 2 ciągi tokena JWT).

Podpisany token JWT (czyli wszystkie 3 ciągi znaków połączone kropkami) jest wysyłany do usługi web push jako nagłówek Authorization z dołączonym nagłówkiem WebPush, np.:

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

Protokół Web Push Protocol określa też, że kluczem publicznego serwera aplikacji musi być wysłane w nagłówku Crypto-Key jako bezpieczny dla adresu URL ciąg zakodowany w standardzie base64 z atrybutem p256ecdsa= została do niego dodana.

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

Szyfrowanie ładunku

Następnie przyjrzyjmy się, jak wysłać ładunek z wiadomością push, aby nasza aplikacja internetowa mogła uzyskać dostęp do danych, gdy otrzyma wiadomość push.

Osoby, które korzystały z innych usług przesyłania powiadomień push, często zadają pytanie, dlaczego dane przesyłane przez internet muszą być szyfrowane. W przypadku aplikacji natywnych powiadomienia push mogą wysyłać dane w postaci zwykłego tekstu.

Jedną z zalet web push jest to, że wszystkie usługi push korzystają z tego samego interfejsu API (protokołu web push), więc deweloperzy nie muszą się martwić, do kogo należy dana usługa push. Możemy wysłać żądanie w odpowiednim formacie i oczekiwać, że zostanie wysłana wiadomość push. Wadą tego rozwiązania jest to, że deweloperzy mogą wysyłać wiadomości do niezaufanej usługi push. Dzięki zaszyfrowaniu ładunku usługa push nie może odczytać wysłanych danych. Tylko przeglądarka może odszyfrować informacje. Dzięki temu dane użytkownika są chronione.

Szyfrowanie ładunku jest zdefiniowane w sekcji Message Encryption specyfikacja.

Zanim przyjrzymy się konkretnym krokom szyfrowania ładunku wiadomości push, powinniśmy omówić pewne techniki, które zostaną użyte do szyfrowania proces tworzenia konta. (Dziękujemy Matowi Scalesowi za jego świetny artykuł na temat szyfrowania push).

ECDH i HKDF

W całym procesie szyfrowania używane są zarówno ECDH, jak i HKDF. Zapewniają one korzyści szyfrowania informacji.

ECDH: wymiana kluczy Diffiego-Hellmana na krzywej eliptycznej

Załóżmy, że mamy 2 osoby, które chcą udostępnić informacje: Alicja i Robert. Zarówno Alicja, jak i Robert mają własne klucze publiczne i prywatne. Alicja i Robert udostępniają sobie klucze publiczne.

Przydatną właściwością kluczy wygenerowanych za pomocą ECDH jest to, że Alicja może używać jej klucz prywatny i klucz publiczny Roberta, aby utworzyć wartość obiektu tajnego „X”. Robert potrafi używając swojego klucza prywatnego i klucza publicznego Alicji do niezależnie tworzą tę samą wartość „X”. Dzięki temu „X” staje się wspólną tajemnicą, a Alicja i Bob musieli udostępnić tylko swój klucz publiczny. Teraz Robert i Alicja można użyć znaku „X” szyfrowania i odszyfrowywania wiadomości między nimi.

Zgodnie z moją najlepszą wiedzą ECDH definiuje właściwości krzywych, które umożliwiają tę „cechę” wspólnego sekretu „X”.

To ogólne omówienie ECDH. Jeśli chcesz dowiedzieć się więcej, zachęcam do obejrzenia tego filmu.

Jeśli chodzi o kod, większość języków / platform ma biblioteki, dzięki którym które można łatwo wygenerować.

W węźle wyglądaliśmy tak:

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

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

HKDF: funkcja derywacji klucza oparta na HMAC

Wikipedia zawiera krótki opis HKDF:

HKDF to oparta na HMAC funkcja derywacji kluczy, która przekształca każdy słaby klucz do materiału klucza kryptograficznego. Można go na przykład użyć do przekształcenia tajnych kluczy wygenerowanych przy użyciu algorytmu Diffie-Hellman w materiały kluczowe odpowiednie do szyfrowania, sprawdzania integralności lub uwierzytelniania.

Zasadniczo HKDF przyjmuje dane wejściowe, które nie są szczególnie bezpieczne, i czyni je bezpieczniejszymi.

Specyfikacja definiująca to szyfrowanie wymaga użycia SHA-256 jako naszego algorytmu szyfrowania a wynikowe klucze HKDF w web push nie powinny być dłuższe niż 256 bitów (32 bajty).

W węźle można to zaimplementować w następujący sposób:

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

Wskazówka na temat przykładowego kodu w artykule Mat Scale.

Dotyczy to w ogólnym zarysie ECDH i HKDF.

ECDH to bezpieczny sposób udostępniania kluczy publicznych i generowania udostępnionego klucza tajnego. HKDF to dobry sposób, i zabezpieczyć materiały użytkowników.

Będzie on używany podczas szyfrowania naszego ładunku. Teraz przyjrzyjmy się temu, co bierzemy pod uwagę jako dane wejściowe i jak je szyfrujemy.

Dane wejściowe

Aby wysłać do użytkownika wiadomość push z ładunkiem, potrzebujemy 3 danych wejściowych:

Payload.
Obiekt tajny auth z PushSubscription.
Klucz p256dh z urządzenia PushSubscription.

Wartości auth i p256dh zostały pobrane z poziomu tabeli PushSubscription. Przypominamy, że w przypadku subskrypcji potrzebujemy tych wartości:

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

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

Wartość auth powinna być traktowana jako obiekt tajny i nie powinna być udostępniana poza Twoją aplikację.

Klucz p256dh jest kluczem publicznym, który czasami nazywany jest kluczem publicznym klienta. Tutaj będziemy nazywać p256dh kluczem publicznym subskrypcji. Klucz publiczny subskrypcji jest generowany. przez przeglądarkę. Przeglądarka zachowa klucz prywatny w tajemnicy i użyje go do odszyfrowywania ładunek.

Te 3 wartości: auth, p256dh i payload są potrzebne jako dane wejściowe, a wynik procesu szyfrowania będzie szyfrowanym ładunkiem, wartością soli i kluczem publicznym używanym tylko do szyfrowania danych.

Sól

Ciąg zaburzający musi mieć 16 bajtów losowych danych. Aby utworzyć sól w Node.js, wykonaj te czynności:

const salt = crypto.randomBytes(16);

Klucze publiczne / prywatne

Klucze publiczne i prywatne powinny być generowane za pomocą krzywej eliptycznej P-256, co w Node wygląda tak:

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

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

Będziemy je nazywać „kluczami lokalnymi”. Służą one tylko do szyfrowania. nic nie ma nic wspólnego z kluczami serwera aplikacji.

Mając dane ładunku, tajny klucz uwierzytelniający i klucz publiczny subskrypcji jako dane wejściowe oraz nowo wygenerowaną sól i zestaw kluczy lokalnych, możemy przeprowadzić szyfrowanie.

Udostępniony klucz tajny

Pierwszym krokiem jest utworzenie udostępnionego obiektu tajnego za pomocą klucza publicznego subskrypcji i naszego nowego klucz prywatny (pamiętasz wyjaśnienie ECDH z Alicją i Robertem? w taki sposób).

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

Będzie on używany w następnym kroku do obliczania pseudolosowego klucza (PRK).

Pseudolosowy klucz

Pseudolosowy klucz (PRK) stanowi kombinację uwierzytelniania subskrypcji push i udostępniony przez nas przed chwilą.

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

Być może zastanawiasz się, do czego służy ciąg znaków Content-Encoding: auth\0. Krótko mówiąc, nie ma ona jasnego celu, chociaż przeglądarki mogą odszyfrować wiadomość przychodzącą i wyszukać oczekiwane kodowanie treści. \0 dodaje bajt o wartości 0 na końcu bufora. To jest spodziewane przez przeglądarki odszyfrowujące wiadomość, które oczekują takiej liczby bajtów dla kodowania treści, po którym następuje bajt z wartością 0, po nim zaszyfrowanych danych.

Nasz pseudo losowy klucz uruchamia po prostu uwierzytelnianie, udostępniony tajny klucz i informację o kodowaniu. za pomocą HKDF (tj. wzmocnić kryptograficznie).

Kontekst

„Kontekst” to zbiór bajtów, który służy do obliczania dwóch wartości w późniejszym etapie szyfrowania w przeglądarce. Jest to tablica bajtów zawierająca klucz publiczny subskrypcji i klucz publiczny lokalny.

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

Ostatni bufor kontekstu to etykieta, liczba bajtów w kluczu publicznym subskrypcji, a następnie sam klucz, a potem liczba bajtów lokalnego klucza publicznego i sam klucz.

Dzięki tej wartości kontekstowej możemy jej użyć do utworzenia liczby jednorazowej i klucza szyfrowania treści (CEK).

Klucz szyfrowania treści i liczba jednorazowa

Numer losowy to wartość, która zapobiega atakom metodą powtórzenia, ponieważ powinna być użyta tylko raz.

Klucz szyfrujący dane (CEK) to klucz, który ostatecznie zostanie użyty do zaszyfrowania ładunku.

Najpierw musimy utworzyć bajty danych dla nonce i CEK, czyli po prostu ciąg znaków kodowania treści, po którym następuje obliczony przez nas bufor kontekstu:

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

Te informacje są sprawdzane przez HKDF, łącząc sól i PRK z wartościami nonceInfo i 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);

Dzięki temu otrzymujemy klucz szyfrowania treści i klucz szyfrowania nonce.

Szyfrowanie

Teraz, gdy mamy klucz szyfrowania treści, możemy zaszyfrować ładunek.

Tworzymy szyfr AES128 za pomocą klucza szyfrowania treści , a liczba jednorazowa jest wektorem inicjującym.

W Node wygląda to tak:

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

Zanim zaszyfrujemy ładunek, musimy określić, ile wypełniacza chcemy dodać na początku ładunku. Powody, dla których warto dodać dopełnienie jest to, że zapobiega ono ryzyku, że podsłuch mogą określić, "typy" wiadomości na podstawie rozmiaru ładunku.

Musisz dodać 2 bajty wypełniacza, aby wskazać długość dodatkowego wypełniacza.

Jeśli na przykład nie dodasz wypełnienia, będą 2 bajty o wartości 0, co oznacza, że nie ma wypełnienia. Po tych 2 bajtach będziesz odczytywać ładunek. Jeśli dodano 5 bajtów dopełnienia, pierwsze 2 bajty będą miały wartość 5, więc konsument następnie odczyta 5 dodatkowych bajtów, a następnie rozpocznie odczytywanie ładunku.

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

Następnie przesyłamy wypełnienie i ładunek za pomocą tego szyfru.

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

Mamy już zaszyfrowany ładunek. Hura!

Pozostaje tylko określić, jak przesłać ładunek do usługi push.

Nagłówki zaszyfrowanych ładunków i ciało

Aby wysłać zaszyfrowane dane do usługi push, musimy zdefiniować w żądaniu POST kilka różnych nagłówków.

Nagłówek szyfrowania

Szyfrowanie nagłówek musi zawierać element salt używany do szyfrowania ładunku.

Ten 16-bajtowy ciąg zaburzający powinien być zakodowany w bezpieczny sposób przy użyciu adresu URL w base64 i dodany do nagłówka Szyfrowanie w następujący sposób:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Nagłówek Crypto-Key

Zauważyliśmy, że nagłówek Crypto-Key jest używany w sekcji „Klucze serwera aplikacji” do przechowywania publicznego klucza serwera aplikacji.

Ten nagłówek jest też używany do udostępniania lokalnego klucza publicznego używanego do szyfrowania ładunek.

Wygenerowany nagłówek wygląda tak:

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

Nagłówki typu treści, długości i kodowania

Nagłówek Content-Length to liczba bajtów w zaszyfrowanym ładunku. Content-Type oraz „Content-Encoding” nagłówki mają stałe wartości. Widać to poniżej.

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

Po ustawieniu tych nagłówków musimy wysłać zaszyfrowany ładunek jako treść od naszego żądania. Zwróć uwagę, że pole Content-Type jest ustawione na application/octet-stream Dzieje się tak, ponieważ zaszyfrowane dane muszą być wysyłane jako strumień bajtów.

W Node.js w ten sposób:

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

Więcej nagłówków?

Omówiliśmy nagłówki używane w przypadku kluczy JWT i kluczy serwera aplikacji (np. jak identyfikować aplikację za pomocą usługi push) oraz nagłówki używane do wysyłania zaszyfrowanego ładunku.

Istnieją dodatkowe nagłówki, których używają usługi push, aby zmienić sposób działania wysyłanych wiadomości. Niektóre z tych nagłówków są wymagane, a inne opcjonalne.

Nagłówek TTL

Wymagany

TTL (lub czas życia) to liczba całkowita określająca liczbę sekund, przez jaką wiadomość push ma być dostępna w usłudze push, zanim zostanie dostarczona. Gdy wygaśnie TTL, wiadomość zostanie usunięta z w kolejce usług push i nie zostanie ona dostarczona.

TTL: [Time to live in seconds]

Jeśli ustawisz TTL na 0, usługa push będzie próbować dostarczyć możesz wysłać wiadomość od razu, ale jeśli nie będzie można połączyć się z urządzeniem, zostanie natychmiast usunięty z kolejki usługi push.

Technicznie rzecz biorąc, usługa push może zmniejszyć TTL wiadomości push, jeśli domaga się nowych praw. Aby sprawdzić, czy tak się stało, sprawdź nagłówek TTL w odpowiedzi od usługi przesyłania informacji.

Temat

Opcjonalny

Tematy to ciągi tekstowe, które mogą zastąpić oczekujące wiadomości nowe wiadomości, jeśli mają pasujące nazwy tematów.

Jest to przydatne w sytuacjach, gdy wysyłanych jest wiele wiadomości gdy urządzenie jest offline i chcesz, by użytkownik widział tylko najnowsze informacje gdy urządzenie jest włączone.

Pilność

Opcjonalny

Pilność wskazuje usłudze push, jak ważna jest wiadomość dla użytkownika. Usługa push może używać tej funkcji, aby oszczędzać czas pracy na baterii urządzenia użytkownika, budząc go tylko w przypadku ważnych wiadomości, gdy poziom naładowania baterii jest niski.

Wartość nagłówka jest zdefiniowana jak poniżej. Wartością domyślną jest normal.

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

Wszystko razem

Jeśli masz więcej pytań na temat tego, jak to działa, możesz sprawdzić, jak biblioteki wywołują wiadomości push na stronie web-push-libs.org.

Gdy masz już zaszyfrowany ładunek i wymienione powyżej nagłówki, wystarczy wysłać żądanie POST do endpoint w ramach PushSubscription.

Co zrobić z odpowiedzią na to żądanie POST?

Odpowiedź z usługi push

Po wysłaniu żądania do usługi powiadomień push należy sprawdzić kod stanu odpowiedzi, aby dowiedzieć się, czy żądanie zostało zrealizowane.

Kod stanu	Opis
201	Utworzono. Otrzymaliśmy i zaakceptowaliśmy prośbę o wysłanie powiadomienia push.
429	Zbyt wiele żądań. Oznacza to, że serwer aplikacji osiągnął limit szybkości w usłudze push. Usługa push powinna zawierać polecenie „Ponów próbę po” nagłówek, który określa, po jakim czasie można wysłać kolejne żądanie.
400	Nieprawidłowe żądanie. Zwykle oznacza to, że jeden z nagłówków jest nieprawidłowy lub ma nieprawidłowy format.
404	Nie znaleziono. Oznacza to, że subskrypcja wygasła i nie można jej używać. W takim przypadku należy usunąć obiekt `PushSubscription` i poczekać, aż klient ponownie subskrybuje użytkownika.
410	Brak. Subskrypcja nie jest już ważna i należy ją usunąć z serwera aplikacji. Można to odtworzyć, wywołując funkcję unsubscribe() w klasie PushSubscription.
413	Rozmiar ładunku jest zbyt duży. Minimalny rozmiar ładunku danych, który musi obsługiwać usługa push, to 4096 bajtów(lub 4 KB).

Więcej informacji o kodach stanu HTTP znajdziesz w standardzie Web Push (RFC8030).