Web Push-Protokoll

Wir haben gesehen, wie eine Bibliothek zum Auslösen von Push-Nachrichten verwendet werden kann. genau funktionieren diese Bibliotheken?

Sie stellen Netzwerkanfragen und stellen gleichzeitig sicher, das richtige Format zu finden. Die Spezifikation, die diese Netzwerkanfrage definiert, ist die Web-Push-Protokoll.

In diesem Abschnitt wird beschrieben, wie sich der Server mit der Anwendung identifizieren kann. Serverschlüssel und wie die verschlüsselte Nutzlast und die zugehörigen Daten gesendet werden.

Das ist keine schöne Seite von Web-Push und ich bin kein Experte für Verschlüsselung, aber schauen wir uns denn es ist praktisch zu wissen, was diese Bibliotheken im Hintergrund tun.

Anwendungsserverschlüssel

Wenn wir einen Nutzer abonnieren, übergeben wir ein applicationServerKey. Dieser Schlüssel ist an den Push-Dienst übergeben und überprüft, ob die abonnierte Anwendung ist der Nutzer auch die Anwendung, die Push-Nachrichten auslöst.

Wenn wir eine Push-Nachricht auslösen, senden wir eine Reihe von Headern, Push-Dienst die Anwendung zu authentifizieren. (Dies ist definiert als gemäß der VAPID-Spezifikation)

Was bedeutet das eigentlich und was geschieht genau? Das sind die Schritte, Anwendungsserver-Authentifizierung:

1. Der Anwendungsserver signiert einige JSON-Informationen mit seinem privaten Anwendungsschlüssel.
2. Diese signierten Informationen werden als Header in einer POST-Anfrage an den Push-Dienst gesendet.
3. Der Push-Dienst verwendet den gespeicherten öffentlichen Schlüssel, den er von pushManager.subscribe(), um zu prüfen, ob die erhaltenen Informationen unterzeichnet wurden den privaten Schlüssel, der sich auf den öffentlichen Schlüssel bezieht. Hinweis: Der öffentliche Schlüssel ist applicationServerKey, der an den „Subscribe“-Aufruf übergeben wurde.
4. Wenn die signierten Informationen gültig sind, sendet der Push-Dienst die Push-Benachrichtigung Nachricht an den Nutzer.

Ein Beispiel für diesen Informationsfluss finden Sie unten. In der Legende unten links sehen Sie, öffentlichen und privaten Schlüsseln.)

Die „signierten Informationen“ dem Header in der Anfrage hinzugefügt wird, ist ein JSON Web Token.

JSON-Webtoken

Ein JSON-Webtoken (oder kurz JWT) ist eine eine Nachricht an Dritte zu senden, damit der Empfänger wer sie gesendet hat.

Wenn Dritte eine Nachricht erhalten, müssen sie die Absender öffentlichen Schlüssels und überprüfen damit die Signatur des JWT. Wenn die Signatur ist gültig, muss das JWT mit dem übereinstimmenden privater Schlüssel, d. h. muss vom erwarteten Absender stammen.

Auf https://jwt.io/ gibt es eine Vielzahl von Bibliotheken, die Signatur für Sie übernehmen kann. Ich empfehle Ihnen, dies dort zu tun, können. Der Vollständigkeit halber sehen wir uns an, wie ein signiertes JWT manuell erstellt wird.

Web-Push und signierte JWTs

Ein signiertes JWT ist nur ein String, auch wenn man sich drei Strings vorstellen kann, die miteinander verbunden sind. Punkte.

Der erste und zweite String (die JWT-Informationen und JWT-Daten) sind Teile JSON mit base64 codiert, was bedeutet, dass es öffentlich lesbar ist.

Der erste String enthält Informationen zum JWT selbst und gibt an, welcher Algorithmus zum Erstellen der Signatur verwendet wurde.

Die JWT-Informationen für Web-Push müssen die folgenden Informationen enthalten:

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

Der zweite String sind die JWT-Daten. Sie liefert Informationen zum Sender des JWT, ist und wie lange sie gültig ist.

Bei Web-Push hätten die Daten folgendes Format:

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

Der Wert aud ist die „Zielgruppe“, d.h. für wen das JWT bestimmt ist. Für das Web: „Zielgruppe“ ist der Push-Dienst, also legen wir dafür den Ursprung des Push-

Der Wert exp gibt den Ablauf des JWT an. Dadurch wird verhindert, dass Snoopers ein abgefangenes JWT wiederverwenden. Der Ablauf ist ein Zeitstempel in Sekunden und darf nicht mehr 24 Stunden betragen.

In Node.js wird die Ablaufzeit so festgelegt:

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

Es sind 12 statt 24 Stunden, Probleme mit Zeitunterschieden zwischen der sendenden Anwendung und dem Push-Dienst.

Schließlich muss der Wert sub entweder eine URL oder eine mailto-E-Mail-Adresse sein. So kann ein Push-Dienst den Absender kontaktieren, Kontaktinformationen aus dem JWT. Aus diesem Grund benötigte die Web-Push-Bibliothek E-Mail-Adresse).

Genau wie die JWT-Informationen werden die JWT-Daten als URL-sichere Base64-Codierung .

Die dritte Zeichenfolge, die Signatur, ergibt sich aus den ersten beiden Zeichenfolgen, (die JWT-Informationen und JWT-Daten). Diese werden mit einem Punkt verbunden. rufen Sie das „unsignierte Token“ auf und signieren Sie es.

Beim Signaturvorgang muss das „nicht signierte Token“ verschlüsselt werden mit ES256. Gemäß JWT steht, steht ES256 für „ECDSA mit der P-256-Kurve“ und SHA-256-Hash-Algorithmus“. Mit Web-Kryptografie können Sie die Signatur so erstellen:

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

Ein Push-Dienst kann ein JWT mit dem öffentlichen Anwendungsserverschlüssel validieren um die Signatur zu entschlüsseln und sicherzustellen, dass der entschlüsselte String derselbe ist als „nicht signiertes Token“ (d.h. die ersten beiden Strings im JWT).

Das signierte JWT (d. h. alle drei Strings, die durch Punkte verbunden sind) wird an das Web gesendet. Push-Dienst als Authorization-Header mit vorangestelltem WebPush:

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

Im Web Push Protocol steht außerdem, dass der öffentliche Anwendungsserverschlüssel im Crypto-Key-Header als URL-sicherer Base64-codierter String mit p256ecdsa= wurde dem Element vorangestellt.

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

Nutzlastverschlüsselung

Als Nächstes schauen wir uns an, wie wir eine Nutzlast mit einer Push-Nachricht senden können, damit, wenn unsere Webanwendung eine Push-Nachricht erhält, kann er auf die empfangenen Daten zugreifen.

Wer bereits andere Push-Dienste verwendet hat, stellt sich häufig die Frage, warum das Web Nutzlast verschlüsselt werden? Bei systemeigenen Apps können Push-Nachrichten Daten als unformatierten Text senden.

Das Schöne an Web-Push ist, dass alle Push-Dienste das API (Web-Push-Protokoll) verwenden, ist es für Entwickler nicht wichtig, Push-Dienst ist. Wir können eine Anfrage im richtigen Format stellen und erwarten Push-Nachricht zu senden. Der Nachteil ist, dass Entwickler Nachrichten an einen Push-Dienst senden, der nicht vertrauenswürdig ist. Von die Nutzlast verschlüsselt, kann ein Push-Dienst die gesendeten Daten nicht lesen. Nur der Browser kann die Informationen entschlüsseln. So wird die Daten.

Die Verschlüsselung der Nutzlast wird im Abschnitt zur Nachrichtenverschlüsselung Spezifikation.

Bevor wir uns die spezifischen Schritte zum Verschlüsseln einer Nutzlast von Push-Nachrichten ansehen, sollten wir einige Techniken behandeln, die bei der Verschlüsselung . (Mat Scales mit einem Hut für seinen ausgezeichneten Artikel encryption.)

ECDH und HKDF

Sowohl ECDH als auch HKDF werden während des gesamten Verschlüsselungsprozesses verwendet und bieten Vorteile für die der Verschlüsselung von Informationen.

ECDH: Diffie-Hellman-Schlüsselaustausch für elliptische Kurven

Stellen Sie sich vor, Sie haben zwei Personen, die Informationen austauschen möchten, Alice und Bob. Sowohl Alice als auch Bob haben eigene öffentliche und private Schlüssel. Alice und Bob ihre öffentlichen Schlüssel austauschen können.

Die nützliche Eigenschaft der mit ECDH generierten Schlüssel besteht darin, dass Alice ihre privaten Schlüssel und Bobs öffentlichen Schlüssel, um den geheimen Wert "X" zu erstellen. Das kann Bob tun Dabei nahm er seinen privaten Schlüssel und den öffentlichen Schlüssel von Anne unabhängig voneinander den gleichen Wert 'X'. Das macht „X“ ein gemeinsames Secret und Alice und Bob mussten nur ihren öffentlichen Schlüssel teilen. Jetzt sind Bob und Alice kann „X“ verwenden um Nachrichten zwischen ihnen zu verschlüsseln und zu entschlüsseln.

ECDH definiert nach meinem besten Wissen die Eigenschaften von Kurven, die dieses „Merkmal“ ermöglichen. eines gemeinsamen Secrets „X“.

Dies ist eine allgemeine Erläuterung des ECDH. Weitere Informationen findest du in diesem Video.

Was den Code angeht: die meisten Sprachen / Plattformen mit Bibliotheken ausgestattet sind, diese Schlüssel einfach zu generieren.

Im Knoten würden wir Folgendes tun:

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

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

HKDF: HMAC-basierte Schlüsselableitungsfunktion

Wikipedia hat eine kurze Beschreibung von HKDF:

HKDF ist eine HMAC-basierte Schlüsselableitungsfunktion, die jeden schwachen Schlüssel transformiert. in kryptografisch starkes Schlüsselmaterial umgewandelt. Sie kann verwendet werden, Um die von Diffie Hellman ausgetauschten geheimen Schlüssel in Schlüsselmaterial umzuwandeln, Geeignet für die Verschlüsselung, Integritätsprüfung oder Authentifizierung.

Im Wesentlichen nimmt HKDF Eingaben an, die nicht besonders sicher sind, und macht sie sicherer.

Gemäß der Spezifikation, durch die diese Verschlüsselung definiert wird, muss SHA-256 als Hash-Algorithmus verwendet werden Die resultierenden Schlüssel für HKDF in Web-Push sollten nicht länger als 256 Bit sein. (32 Byte).

Im Knoten könnte dies so implementiert werden:

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

Huttipp zum Artikel von Mat Scale für diesen Beispielcode.

Hiermit wird ECDH lose behandelt. und HKDF.

ECDH bietet eine sichere Möglichkeit, öffentliche Schlüssel freizugeben und ein gemeinsames Secret zu generieren. HKDF ist eine Möglichkeit, unsicherem Material und sicher ist.

Diese wird während der Verschlüsselung unserer Nutzlast verwendet. Sehen wir uns als Nächstes an, und wie diese verschlüsselt wird.

Eingaben

Wenn wir eine Push-Nachricht mit einer Nutzlast an einen Nutzer senden möchten, sind drei Eingaben erforderlich:

1. Die Nutzlast selbst.
2. Das auth-Secret von PushSubscription.
3. Den p256dh-Schlüssel von PushSubscription.

Die Werte auth und p256dh werden aus einer PushSubscription abgerufen, Zur Erinnerung: Bei einem Abo benötigen wir folgende Werte:

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

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

Der auth-Wert sollte als geheim behandelt und nicht außerhalb Ihrer Anwendung weitergegeben werden.

Der Schlüssel p256dh ist ein öffentlicher Schlüssel. Dieser Schlüssel wird manchmal als öffentlicher Clientschlüssel bezeichnet. Hier nennen wir p256dh als öffentlichen Aboschlüssel. Der öffentliche Aboschlüssel wird generiert durch den Browser. Der Browser behält den privaten Schlüssel geheim und entschlüsselt damit den Payload.

Diese drei Werte, auth, p256dh und payload, werden als Eingaben und als Ergebnis der besteht aus der verschlüsselten Nutzlast, einem Salt-Wert und einem öffentlichen Schlüssel, der nur für die Verschlüsselung der Daten.

Salz

Der Salt muss 16 Byte an zufälligen Daten umfassen. In NodeJS würden wir den Salt folgendermaßen erstellen:

const salt = crypto.randomBytes(16);

Öffentliche / private Schlüssel

Der öffentliche und der private Schlüssel sollten mit einer elliptischen P-256-Kurve generiert werden. In Node.js würden wir das so tun:

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

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

Diese Schlüssel werden als „lokale Schlüssel“ bezeichnet. Sie werden nur zur Verschlüsselung verwendet und nichts mit Anwendungsserverschlüsseln zu tun.

Mit der Nutzlast, dem Authentifizierungsgeheimnis und dem öffentlichen Aboschlüssel als Eingabe und mit einem neu generierten Salt und einen Satz lokaler Schlüssel haben, sind wir bereit für die Verschlüsselung.

Gemeinsames Secret

Der erste Schritt besteht darin, ein gemeinsames Secret mit dem öffentlichen Aboschlüssel und dem neuen privaten Schlüssel (erinnern Sie sich an die ECDH-Erklärung mit Alice und Bob? einfach so).

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

Er wird im nächsten Schritt zur Berechnung des Pseudozufallsschlüssels (PRK) verwendet.

Pseudozufälliger Schlüssel

Der Pseudozufallsschlüssel (PRK) ist die Kombination aus der Authentifizierung des Push-Abos und das soeben erstellte Secret.

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

Sie fragen sich vielleicht, wofür der String Content-Encoding: auth\0 gedacht ist. Es hat also keinen eindeutigen Zweck, obwohl Browser eine eingehende Nachricht entschlüsseln und nach der erwarteten Inhaltscodierung suchen. \0 fügt dem Ende des Zwischenspeichers ein Byte mit dem Wert 0 hinzu. Dies ist die von Browsern erwartet wird, die die Nachricht entschlüsseln und so viele Bytes erwarten für die Inhaltscodierung, gefolgt von einem Byte mit dem Wert 0, gefolgt vom verschlüsselten Daten.

Bei unserem Pseudozufallsschlüssel werden lediglich die Authentifizierung, der gemeinsame geheime Schlüssel und ein Teil der Codierungsinformationen ausgeführt. über HKDF übertragen (d.h. sie kryptografisch stärker machen).

Kontext

Der „Kontext“ ist eine Menge von Byte, die verwendet werden, um später in der Verschlüsselung zwei Werte zu berechnen. Browser. Es ist im Wesentlichen ein Array von Bytes, das den öffentlichen Aboschlüssel und den lokalen öffentlichen Schlüssel.

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

Der letzte Kontextpuffer ist ein Label, die Anzahl der Byte im öffentlichen Aboschlüssel, gefolgt vom Schlüssel selbst, der Anzahl der Byte des lokalen öffentlichen Schlüssels, gefolgt vom Schlüssel selbst.

Mit diesem Kontextwert können wir ihn zum Erstellen einer Nonce und eines Inhaltsverschlüsselungsschlüssels verwenden. (CEK).

Schlüssel und Nonce für die Inhaltsverschlüsselung

Eine Nonce ist ein Wert, der die Wiederholung verhindert. da sie nur einmal verwendet werden sollten.

Der Content Encryption Key (CEK) ist der Schlüssel, mit dem unsere Nutzlast verschlüsselt wird.

Zunächst müssen wir die Datenbyte für die Nonce und den CEK erstellen. Codierungs-String gefolgt von dem gerade berechneten Kontextpuffer:

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

Diese Informationen werden über HKDF abgerufen, wobei Salt und PRK mit nonceInfo und cekInfo kombiniert werden:

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

Dadurch erhalten wir unseren Nonce- und Content-Verschlüsselungsschlüssel.

Verschlüsselung durchführen

Jetzt haben wir den Schlüssel für die Inhaltsverschlüsselung und können die Nutzlast verschlüsseln.

Wir erstellen eine AES128-Chiffre mithilfe des Content-Verschlüsselungsschlüssels. als Schlüssel und die Nonce ist ein Initialisierungsvektor.

In Node ist dies so:

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

Bevor wir die Nutzlast verschlüsseln, müssen wir festlegen, wie viel Padding der Nutzlast hinzugefügt werden soll. Wir sollten einen Abstand hinzufügen, dass verhindert wird, dass Unbefugte die "Typen" basierend auf der Nutzlastgröße.

Sie müssen zwei Bytes für das Padding hinzufügen, um die Länge des zusätzlichen Paddings anzugeben.

Wenn Sie beispielsweise kein Padding hinzugefügt haben, haben Sie nach diesen beiden Byte zwei Byte mit dem Wert 0, d.h., es ist kein Padding vorhanden, nachdem Sie die Nutzlast gelesen haben. Wenn Sie 5 Byte Padding hinzugefügt haben, haben die ersten beiden Byte den Wert 5. Der Nutzer liest dann weitere fünf Byte und beginnt dann mit dem Lesen der Nutzlast.

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

Anschließend führen wir das Padding und die Nutzlast durch diese Chiffre aus.

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

Jetzt haben wir unsere verschlüsselte Nutzlast. Super!

Jetzt müssen Sie nur noch bestimmen, wie diese Nutzlast an den Push-Dienst gesendet wird.

Verschlüsselte Nutzlast-Header und Text

Um diese verschlüsselte Nutzlast an den Push-Dienst zu senden, müssen wir einige verschiedene Header in unserer POST-Anfrage.

Verschlüsselungsheader

Die „Verschlüsselung“ Der Header muss das salt enthalten, das zum Verschlüsseln der Nutzlast verwendet wurde.

Das 16-Byte-Salt muss mit base64 URL-sicher codiert sein und dem Verschlüsselungsheader wie folgt hinzugefügt werden:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Header für kryptografischen Schlüssel

Wir haben gesehen, dass der Header Crypto-Key unter den „Anwendungsserverschlüsseln“ verwendet wird. , der den öffentlichen Anwendungsserverschlüssel enthält.

Dieser Header wird auch verwendet, um den lokalen öffentlichen Schlüssel für die Verschlüsselung freizugeben die Nutzlast.

Der resultierende Header sieht so aus:

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

Inhaltstyp, Länge und Codierung von Headern

Der Header Content-Length ist die Anzahl der Byte im verschlüsselten Payload. 'Inhaltstyp' und "Content-Encoding" Header sind feste Werte. Dies ist nachstehend zu sehen.

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

Wenn diese Header festgelegt sind, müssen wir die verschlüsselte Nutzlast als Textkörper unserer Anfrage. Beachten Sie, dass Content-Type auf application/octet-stream. Das liegt daran, dass die verschlüsselte Nutzlast als Stream von Byte gesendet.

In NodeJS würde dies wie folgt aussehen:

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

Weitere Überschriften?

Wir haben die Header für JWT-/Anwendungsserverschlüssel behandelt (z.B. wie die mit dem Push-Dienst) und wir haben die Header behandelt, die zum Senden einer verschlüsselten Payload.

Es gibt zusätzliche Header, mit denen Push-Dienste das Verhalten von gesendeten Nachrichten. Einige dieser Header sind erforderlich, andere sind optional.

TTL-Header

Erforderlich

TTL (oder Gültigkeitsdauer) ist eine Ganzzahl, die die Anzahl der Sekunden angibt Ihre Push-Nachricht im Push-Dienst zu veröffentlichen, geliefert wurden. Nach Ablauf der TTL wird die Nachricht aus dem Push-Dienst-Warteschlange und wird nicht zugestellt.

TTL: [Time to live in seconds]

Wenn Sie für TTL null festlegen, versucht der Push-Dienst, Nachricht sofort senden, aber wenn das Gerät nicht erreichbar ist, wird Ihre Nachricht werden sofort aus der Push-Dienst-Warteschlange entfernt.

Technisch gesehen kann ein Push-Dienst die TTL einer Push-Nachricht reduzieren, wenn wünscht. Sie können das feststellen, indem Sie den Header TTL in die Antwort von einem Push-Dienst.

Thema

Optional

Themen sind Strings, mit denen ausstehende Nachrichten durch einen neue Nachricht, wenn sie passende Themennamen haben.

Dies ist nützlich in Szenarien, in denen mehrere Nachrichten gesendet werden, während ein Gerät offline ist und Sie möchten, dass die Nutzer nur die aktuellen angezeigt, wenn das Gerät eingeschaltet wird.

Dringlichkeit

Optional

Die Dringlichkeit gibt für den Push-Dienst an, wie wichtig eine Nachricht für den Nutzer ist. Dieses kann vom Push-Dienst verwendet werden, um die Akkulaufzeit eines Geräts zu verlängern, indem wenn der Akku schwach ist und Sie bei wichtigen Nachrichten aufwachen.

Der Headerwert wird wie unten dargestellt definiert. Der Standardwert ist normal

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

Alles zusammen

Wenn Sie weitere Fragen zur Funktionsweise haben, können Sie jederzeit nachsehen, wie Bibliotheken ausgelöst werden. Push-Nachrichten in der Organisation „web-push-libs“.

Sobald Sie eine verschlüsselte Nutzlast und die obigen Header haben, müssen Sie nur noch eine POST-Anfrage stellen. zu endpoint in einem PushSubscription.

Was machen wir also mit der Antwort auf diese POST-Anfrage?

Antwort vom Push-Dienst

Nachdem Sie eine Anfrage an einen Push-Dienst gesendet haben, müssen Sie den Statuscode der Antwort, da sie Aufschluss darüber gibt, ob die Anfrage erfolgreich war oder nicht.

Weitere Informationen

• Web-Push-Benachrichtigungen – Übersicht
• Funktionsweise von Push
• Nutzer abonnieren
• UX der Berechtigung
• Nachrichten mit Web-Push-Bibliotheken senden
• Web-Push-Protokoll
• Umgang mit Push-Ereignissen
• Benachrichtigungen anzeigen
• Benachrichtigungsverhalten
• Allgemeine Benachrichtigungsmuster
• FAQs zu Push-Benachrichtigungen
• Häufige Probleme und Fehler melden

Code labs

• Client für Push-Benachrichtigungen erstellen
• Push-Benachrichtigungsserver erstellen