Protokół Web Push Protocol

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 definiująca to żądanie sieciowe to Protokół Web Push Protocol.

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 przyjemna kwestia w postaci web push i nie znam się na szyfrowaniu, ale przyjrzyjmy się dokładniej bo dobrze jest wiedzieć, jak te biblioteki robią.

Klucze serwera aplikacji

Gdy rejestrujemy użytkownika, przekazujemy applicationServerKey. Ten klucz jest przekazywane do usługi push i używane do sprawdzania, czy aplikacja subskrybująca to użytkownik jest też aplikacją, która wywołuje komunikaty push.

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

Co to wszystko oznacza i co dokładnie się dzieje? Oto kroki, jakie podejmujemy, uwierzytelnianie serwera aplikacji:

1. Serwer aplikacji podpisuje niektóre informacje JSON swoim prywatnym kluczem aplikacji.
2. Te podpisane informacje są wysyłane do usługi push jako nagłówek w żądaniu POST.
3. 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 przekazać do wywołania subskrypcji.
4. Jeśli podpisane informacje są prawidłowe, usługa push wysyła metodę push wiadomość do użytkownika.

Przykład tego przepływu informacji znajduje się poniżej. (Legenda w lewym dolnym rogu wskazuje, klucz publiczny i prywatny).

„Podpisane informacje” dodany do nagłówka w żądaniu jest tokenem sieciowym JSON.

Token sieciowy 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, więc token JWT musi być podpisany zgodnym klucz prywatny, 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. Aby uzyskać komplet informacji, 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że być interpretowany jako 3 połączone ciągi według kropek.

Pierwszy i drugi ciąg znaków (informacje JWT i dane JWT) są fragmentami Plik JSON zakodowany w standardzie base64, co oznacza, że jest dostępny 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 oznacza datę wygaśnięcia tokena JWT, co zapobiega służbom mogą ponownie użyć tokena JWT, jeśli go przechwytuje. Data ważności to sygnatura czasowa w sekund i nie może wynosić więcej niż 24 godziny.

W Node.js czas do wygaśnięcia jest ustawiany 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 musiała skontaktować się z nadawcą, może znaleźć dane kontaktowe z JWT. (Właśnie dlatego biblioteka webpush wymaga i adres e-mail).

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

Trzeci ciąg, podpis, jest wynikiem zastosowania dwóch pierwszych ciągów (informacja JWT i dane JWT), łącząc je kropką, wywołasz „niepodpisany token” i podpisze go.

Proces podpisywania wymaga zaszyfrowania „niepodpisanego tokena” przy użyciu standardu ES256. Zgodnie z JWT specyfikacja, ES256 to skrót od „ECDSA” z wykorzystaniem krzywej P-256 algorytm szyfrowania SHA-256”. Korzystając z internetowego kryptografii, możesz utworzyć podpis w następujący 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 (tj. wszystkie 3 ciągi połączone kropkami) jest wysyłany do sieci usługi push jako nagłówek Authorization z dodanym WebPush, na przykład:

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

Przyjrzyjmy się teraz, jak wysłać ładunek z komunikatem push, aby nasza aplikacja internetowa otrzyma wiadomość push, może uzyskać dostęp do otrzymanych danych.

Użytkownicy, którzy skorzystali z innych usług push, często zastanawiają się, dlaczego ładunek musi być zaszyfrowany? W przypadku aplikacji natywnych wiadomości push mogą wysyłać dane jako zwykły tekst.

Piękno internetu push polega na tym, że wszystkie usługi API (protokołu web push) nie musi interesować programistów, usług push. Możemy przesłać żądanie we właściwym formacie wiadomość push do wysłania. Wadą tego rozwiązania jest to, że deweloperzy mogą wysyłać wiadomości do niezaufanej usługi push. Według zaszyfrowanie ładunku, usługa push nie może odczytać wysyłanych danych. Tylko przeglądarka może odszyfrować informacje. Pozwala to chronić i skalowalnych danych.

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. (Znakomity kapelusz dla Mat Scalesa za jego rewelacyjny artykuł encryption.)

ECDH i HKDF

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

ECDH: krzywa eliptyczna Diffiego-Hellmana

Wyobraź sobie, że masz dwie osoby, które chcą podzielić się informacjami: Alicję i Roberta. Alicja i Robert mają własne klucze publiczne i prywatne. Alicja i Robert udostępniać sobie nawzajem swoje klucze publiczne.

Przydatną właściwością kluczy wygenerowanych za pomocą ECDH jest to, że Alicja może użyć 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”. To oznacza, że „X” udostępniony tajny klucz a Alicja i Robert musieli udostępnić tylko swój klucz publiczny. Teraz Robert i Alicja można użyć znaku „X” aby szyfrować i odszyfrowywać 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 wyjaśnienie na temat 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 ma zwięzły 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 używać do: aby przekształcić wspólne sekrety w kluczowy materiał. nadaje się do szyfrowania, sprawdzania integralności i uwierzytelniania.

Zasadniczo HKDF pobiera dane, które nie są szczególnie bezpieczne, i zwiększa ich bezpieczeństwo.

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.

Obejmują one ECDH. i HKDF.

ECDH to bezpieczny sposób na udostępnianie kluczy publicznych i generowanie udostępnionego obiektu tajnego. HKDF to dobry sposób, i zabezpieczyć materiały użytkowników.

Będzie on używany podczas szyfrowania naszego ładunku. Następnie przyjrzyjmy się temu, danych wejściowych i sposobu ich szyfrowania.

Dane wejściowe

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

1. samego ładunku.
2. Obiekt tajny auth z PushSubscription.
3. Klucz p256dh z PushSubscription.

Widzimy, że wartości auth i p256dh są pobierane z tabeli PushSubscription, ale dla przypominamy, że w przypadku subskrypcji potrzebne są te 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 używać p256dh jako klucza publicznego 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 i wynik funkcji będzie zaszyfrowanym ładunkiem, wartością ciągu zaburzającego i kluczem publicznym, które są używane 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 należy wygenerować za pomocą krzywej eliptycznej P-256, w Node.js, w ten sposób:

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.

z ładunkiem, tajnym kluczem uwierzytelniania i kluczem publicznym subskrypcji jako danymi wejściowymi oraz nowo wygenerowanym kluczem za pomocą ciągu zaburzającego i zestawu kluczy lokalnych, możemy zająć się szyfrowaniem.

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 od Alicji i Roberta? w taki sposób).

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

Jest on używany w następnym kroku do obliczania pseudolosowego klucza losowego (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 Content-Encoding: auth\0. Krótko mówiąc, nie ma ona wyraźnego 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 późniejszego obliczenia dwóch wartości w szyfrowaniu przeglądarki. Zasadniczo jest to tablica bajtów zawierająca klucz publiczny subskrypcji i lokalnego klucza publicznego.

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

Ostatnim buforem kontekstu jest etykieta, liczba bajtów w kluczu publicznym subskrypcji, po nim jest cały klucz, potem liczba bajtów lokalnego klucza publicznego, a następnie 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

Jednorazowa to wartość, która uniemożliwia ponowne odtworzenie. ponieważ należy go użyć tylko raz.

Klucz szyfrowania treści (CEK) to klucz, który zostanie ostatecznie użyty do szyfrowania ładunku.

Najpierw musimy utworzyć bajty danych dla liczby jednorazowej i CEK, które są po prostu zawartością ciąg kodowania, po którym następuje bufor kontekstu, który właśnie obliczyliśmy:

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

Daje nam to klucz jednorazowy i szyfrowanie treści.

Szyfrowanie

Teraz gdy mamy już 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 węźle wygląda to tak:

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

Przed zaszyfrowaniem ładunku musimy określić, jakiego dopełnienia chcemy używać. które należy dodać z przodu ładunku. Powody, dla których warto dodać dopełnienie jest to, że zapobiega ono wykryciu, "typy" wiadomości na podstawie rozmiaru ładunku.

Aby wskazać długość dodatkowego dopełnienia, musisz dodać 2 bajty.

Jeśli na przykład nie dodasz dopełnienia, zostaną zapisane 2 bajty z wartością 0, czyli brak dopełnienia. Po tych 2 bajtach odczytasz ł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 za pomocą tego szyfrowania uruchamiamy dopełnienie i ładunek.

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 teraz zaszyfrowany ładunek. Hura!

Pozostaje już tylko określić, w jaki sposób ładunek będzie wysyłany do usługi push.

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

Aby wysłać ten zaszyfrowany ładunek do usługi push, musimy zdefiniować kilka różne nagłówki w żądaniu POST.

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 w sekcji „Application Server Keys” (Klucze serwera aplikacji) używany jest nagłówek Crypto-Key. do przechowywania klucza publicznego serwera aplikacji.

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

Otrzymany nagłówek będzie wyglądał tak:

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

Typ treści, długość nagłówki kodowania

Nagłówek Content-Length to liczba bajtów w zaszyfrowanym pliku ładunek. Content-Type oraz „Content-Encoding” 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ż zaszyfrowany ładunek musi 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 tokenach JWT / kluczach serwera aplikacji (np. jak zidentyfikować za pomocą usługi push) i omówiliśmy nagłówki służące do wysyłania ładunek.

Istnieją dodatkowe nagłówki, których usługi push używają do zmiany działania wysłane wiadomości. Niektóre z nich są wymagane, a inne – opcjonalne.

Nagłówek TTL

Wymagany

TTL (lub czas życia danych) jest liczbą całkowitą określającą liczbę sekund chcesz, aby wiadomość była dostępna w usłudze push, zanim zostanie dostarczone. 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, przejrzyj nagłówek TTL w: odpowiedź z usługi push.

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. Ten mogą być używane przez usługę push w celu wydłużenia żywotności baterii urządzenia użytkownika wybudzania ważnych komunikatów przy niskim poziomie baterii.

Wartość nagłówka została zdefiniowana poniżej. Domyślny ma wartość normal.

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

Wszystko w jednym miejscu

Jeśli masz więcej pytań na temat tego, jak to wszystko działa, zawsze możesz sprawdzić działanie bibliotek wiadomości push w organizacji web-push-libs.

Po zaszyfrowanym ładunku i nagłówkach wymienionych powyżej wystarczy wysłać żądanie POST do: endpoint w: PushSubscription.

Co więc robimy z odpowiedzią na to żądanie POST?

Odpowiedź z usługi push

Po przesłaniu żądania do usługi push musisz sprawdzić kod stanu bo dowiesz się, czy żądanie zostało zrealizowane lub nie.

Co dalej

• Omówienie powiadomień push w internecie
• Jak działa push
• Subskrybowanie użytkownika
• UX uprawnień
• Wysyłanie wiadomości za pomocą bibliotek Web Push
• protokół Web Push Protocol
• Obsługa zdarzeń push
• Wyświetlanie powiadomienia
• Działanie powiadomień
• Typowe wzorce powiadomień
• Najczęstsze pytania na temat powiadomień push
• Typowe problemy i zgłaszanie błędów

Ćwiczenia z kodowania

• Tworzenie klienta powiadomień push
• Tworzenie serwera powiadomień push