Nous avons vu comment utiliser une bibliothèque pour déclencher des messages push, mais que font exactement ces bibliothèques ?
Eh bien, ils envoient des requêtes réseau tout en s'assurant qu'elles sont au bon format. La spécification qui définit cette requête réseau est le protocole Web Push.
Cette section explique comment le serveur peut s'identifier à l'aide de clés de serveur d'application, et comment la charge utile chiffrée et les données associées sont envoyées.
Ce n'est pas un aspect très agréable des notifications push Web, et je ne suis pas un expert en chiffrement, mais examinons chaque élément, car il est utile de savoir ce que font ces bibliothèques en arrière-plan.
Clés de serveur d'application
Lorsque nous abonnons un utilisateur, nous transmettons un applicationServerKey. Cette clé est transmise au service push et utilisée pour vérifier que l'application qui a abonné l'utilisateur est également celle qui déclenche les messages push.
Lorsque nous déclenchons un message push, nous envoyons un ensemble d'en-têtes qui permettent au service push d'authentifier l'application. (Cette valeur est définie par la spécification VAPID.)
Qu'est-ce que cela signifie et que se passe-t-il exactement ? Voici les étapes de l'authentification du serveur d'applications :
- Le serveur d'applications signe certaines informations JSON avec sa clé d'application privée.
- Ces informations signées sont envoyées au service push en tant qu'en-tête dans une requête POST.
- Le service push utilise la clé publique stockée qu'il a reçue de
pushManager.subscribe()pour vérifier que les informations reçues sont signées par la clé privée associée à la clé publique. Rappel : La clé publique est la valeurapplicationServerKeytransmise dans l'appel d'abonnement. - Si les informations signées sont valides, le service push envoie le message push à l'utilisateur.
Voici un exemple de ce flux d'informations. (Notez la légende en bas à gauche pour indiquer les clés publiques et privées.)
Les "informations signées" ajoutées à un en-tête de la requête sont un jeton Web JSON.
Jeton Web JSON
Un jeton Web JSON (ou JWT) permet d'envoyer un message à un tiers de manière à ce que le destinataire puisse valider l'identité de l'expéditeur.
Lorsqu'un tiers reçoit un message, il doit obtenir la clé publique de l'expéditeur et l'utiliser pour valider la signature du jeton JWT. Si la signature est valide, le jeton JWT doit avoir été signé avec la clé privée correspondante et doit donc provenir de l'expéditeur attendu.
Il existe de nombreuses bibliothèques sur jwt.io/ qui peuvent effectuer la signature à votre place. Je vous recommande de les utiliser dans la mesure du possible. Pour être exhaustif, voyons comment créer manuellement un jeton JWT signé.
Web push et jetons JWT signés
Un jeton JWT signé n'est qu'une chaîne, bien qu'il puisse être considéré comme trois chaînes reliées par des points.
Les première et deuxième chaînes (les informations et les données du jeton JWT) sont des éléments JSON encodés en base64, ce qui signifie qu'ils sont lisibles publiquement.
La première chaîne contient des informations sur le jeton JWT lui-même, indiquant l'algorithme utilisé pour créer la signature.
Les informations JWT pour les notifications push Web doivent contenir les informations suivantes :
{
"typ": "JWT",
"alg": "ES256"
}
La deuxième chaîne correspond aux données du jeton JWT. Il fournit des informations sur l'expéditeur du jeton JWT, son destinataire et sa durée de validité.
Pour les notifications push Web, les données se présentent sous la forme suivante :
{
"aud": "https://some-push-service.org",
"exp": "1469618703",
"sub": "mailto:example@web-push-book.org"
}
La valeur aud correspond à l'audience, c'est-à-dire au destinataire du jeton JWT. Pour les notifications push Web, l'audience est le service push. Nous la définissons donc sur l'origine du service push.
La valeur exp correspond à l'expiration du jeton JWT, ce qui empêche les espions de réutiliser un jeton JWT s'ils l'interceptent. L'expiration est un code temporel en secondes et ne doit pas dépasser 24 heures.
Dans Node.js, l'expiration est définie à l'aide de :
Math.floor(Date.now() / 1000) + 12 * 60 * 60;
La durée est de 12 heures au lieu de 24 heures pour éviter tout problème de différence d'horloge entre l'application d'envoi et le service push.
Enfin, la valeur sub doit être une URL ou une adresse e-mail mailto.
Ainsi, si un service push doit contacter l'expéditeur, il peut trouver ses coordonnées dans le jeton JWT. (C'est pourquoi la bibliothèque web-push avait besoin d'une adresse e-mail.)
Tout comme les informations JWT, les données JWT sont encodées sous forme de chaîne base64 sécurisée pour les URL.
La troisième chaîne, la signature, est le résultat de la prise des deux premières chaînes (les informations JWT et les données JWT), de leur jonction avec un point, que nous appellerons le "jeton non signé", et de sa signature.
Le processus de signature nécessite de chiffrer le "jeton non signé" à l'aide d'ES256. Selon la spécification JWT, ES256 est l'abréviation de "ECDSA utilisant la courbe P-256 et l'algorithme de hachage SHA-256". Avec Web Crypto, vous pouvez créer la signature comme suit :
// 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);
});
Un service push peut valider un jeton JWT à l'aide de la clé publique du serveur d'applications pour déchiffrer la signature et s'assurer que la chaîne déchiffrée est identique au "jeton non signé" (c'est-à-dire les deux premières chaînes du jeton JWT).
Le jeton JWT signé (c'est-à-dire les trois chaînes jointes par des points) est envoyé au service Web Push en tant qu'en-tête Authorization précédé de WebPush, comme suit :
Authorization: 'WebPush [JWT Info].[JWT Data].[Signature]';
Le protocole Web Push stipule également que la clé publique du serveur d'application doit être envoyée dans l'en-tête Crypto-Key sous la forme d'une chaîne encodée en base64 sécurisée pour les URL, précédée de p256ecdsa=.
Crypto-Key: p256ecdsa=[URL Safe Base64 Public Application Server Key]
Le chiffrement de la charge utile
Voyons maintenant comment envoyer une charge utile avec un message push afin que, lorsque notre application Web reçoit un message push, elle puisse accéder aux données qu'elle reçoit.
Une question courante qui se pose à tous ceux qui ont utilisé d'autres services push est la suivante : pourquoi la charge utile push Web doit-elle être chiffrée ? Avec les applications natives, les messages push peuvent envoyer des données sous forme de texte brut.
L'un des avantages des notifications push Web est que, comme tous les services push utilisent la même API (le protocole push Web), les développeurs n'ont pas à se soucier de l'identité du service push. Nous pouvons envoyer une requête au bon format et nous attendre à ce qu'un message push soit envoyé. L'inconvénient est que les développeurs pourraient envoyer des messages à un service push qui n'est pas digne de confiance. En chiffrant la charge utile, un service push ne peut pas lire les données envoyées. Seul le navigateur peut déchiffrer les informations. Cela permet de protéger les données de l'utilisateur.
Le chiffrement de la charge utile est défini dans la spécification de chiffrement des messages.
Avant d'examiner les étapes spécifiques de chiffrement d'une charge utile de message push, nous devons aborder certaines techniques qui seront utilisées pendant le processus de chiffrement. (Un grand merci à Mat Scales pour son excellent article sur le chiffrement push.)
ECDH et HKDF
ECDH et HKDF sont tous deux utilisés tout au long du processus de chiffrement et offrent des avantages pour le chiffrement des informations.
ECDH : échange de clés Diffie-Hellman à courbe elliptique
Imaginez que deux personnes, Alice et Bob, souhaitent partager des informations. Alice et Bob ont chacun leurs propres clés publiques et privées. Alice et Bob partagent leurs clés publiques l'un avec l'autre.
La propriété utile des clés générées avec ECDH est qu'Alice peut utiliser sa clé privée et la clé publique de Bob pour créer la valeur secrète "X". Bob peut faire de même en utilisant sa clé privée et la clé publique d'Alice pour créer indépendamment la même valeur "X". "X" devient ainsi un secret partagé, et Alice et Bob n'ont eu qu'à partager leur clé publique. Robert et Alice peuvent désormais utiliser "X" pour chiffrer et déchiffrer les messages qu'ils s'envoient.
À ma connaissance, ECDH définit les propriétés des courbes qui permettent cette "fonctionnalité" de création d'un secret partagé "X".
Il s'agit d'une explication générale de l'ECDH. Pour en savoir plus, nous vous recommandons de regarder une vidéo de présentation plus détaillée de l'ECDH.
En termes de code, la plupart des langages et plates-formes sont fournis avec des bibliothèques qui facilitent la génération de ces clés.
Dans Node, nous procéderions comme suit :
const keyCurve = crypto.createECDH('prime256v1');
keyCurve.generateKeys();
const publicKey = keyCurve.getPublicKey();
const privateKey = keyCurve.getPrivateKey();
HKDF : fonction de dérivation de clé basée sur HMAC
Wikipédia propose une description succincte de HKDF :
HKDF est une fonction de dérivation de clé basée sur HMAC qui transforme tout matériel de clé faible en matériel de clé cryptographiquement fort. Elle peut être utilisée, par exemple, pour convertir des secrets partagés échangés par Diffie-Hellman en matériel de clé adapté au chiffrement, à la vérification de l'intégrité ou à l'authentification.
En gros, HKDF prend une entrée qui n'est pas particulièrement sécurisée et la rend plus sécurisée.
La spécification définissant ce chiffrement nécessite l'utilisation de SHA-256 comme algorithme de hachage, et les clés résultantes pour HKDF dans les notifications push Web ne doivent pas dépasser 256 bits (32 octets).
Dans Node, cela peut être implémenté comme suit :
// 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);
}
Merci à Mat Scale pour l'article contenant cet exemple de code.
Cela couvre de manière générale ECDH et HKDF.
ECDH est un moyen sécurisé de partager des clés publiques et de générer un secret partagé. HKDF est un moyen de sécuriser des données non sécurisées.
Il sera utilisé lors du chiffrement de notre charge utile. Voyons maintenant ce que nous prenons en entrée et comment cela est chiffré.
Entrées
Lorsque nous voulons envoyer un message push à un utilisateur avec une charge utile, nous avons besoin de trois entrées :
- La charge utile elle-même.
- Le secret
authdePushSubscription. - La clé
p256dhdePushSubscription.
Nous avons vu que les valeurs auth et p256dh sont récupérées à partir d'un PushSubscription. Pour rappel, pour un abonnement, nous avons besoin des valeurs suivantes :
subscription.toJSON().keys.auth;
subscription.toJSON().keys.p256dh;
subscription.getKey('auth');
subscription.getKey('p256dh');
La valeur auth doit être traitée comme un secret et ne doit pas être partagée en dehors de votre application.
La clé p256dh est une clé publique, parfois appelée "clé publique du client". Ici, nous ferons référence à p256dh en tant que clé publique d'abonnement. La clé publique de l'abonnement est générée par le navigateur. Le navigateur garde la clé privée secrète et l'utilise pour déchiffrer la charge utile.
Ces trois valeurs, auth, p256dh et payload, sont nécessaires en tant qu'entrées. Le résultat du processus de chiffrement sera la charge utile chiffrée, une valeur de salage et une clé publique utilisée uniquement pour chiffrer les données.
Salt
Le salage doit être composé de 16 octets de données aléatoires. Dans NodeJS, nous procéderions comme suit pour créer un salage :
const salt = crypto.randomBytes(16);
Clés publiques/privées
Les clés publique et privée doivent être générées à l'aide d'une courbe elliptique P-256, ce que nous ferions dans Node comme suit :
const localKeysCurve = crypto.createECDH('prime256v1');
localKeysCurve.generateKeys();
const localPublicKey = localKeysCurve.getPublicKey();
const localPrivateKey = localKeysCurve.getPrivateKey();
Nous les appellerons "clés locales". Elles ne sont utilisées que pour le chiffrement et n'ont rien à voir avec les clés de serveur d'application.
Avec la charge utile, le secret d'authentification et la clé publique d'abonnement comme entrées, ainsi qu'un sel et un ensemble de clés locales nouvellement générés, nous sommes prêts à effectuer un chiffrement.
Secret partagé
La première étape consiste à créer un secret partagé à l'aide de la clé publique de l'abonnement et de notre nouvelle clé privée (vous vous souvenez de l'explication de l'ECDH avec Alice et Bob ? Juste comme ça).
const sharedSecret = localKeysCurve.computeSecret(
subscription.keys.p256dh,
'base64',
);
Elle est utilisée à l'étape suivante pour calculer la clé pseudo-aléatoire (PRK).
Clé pseudo-aléatoire
La clé pseudo-aléatoire (PRK) est la combinaison du secret d'authentification de l'abonnement push et du secret partagé que nous venons de créer.
const authEncBuff = new Buffer('Content-Encoding: auth\0', 'utf8');
const prk = hkdf(subscription.keys.auth, sharedSecret, authEncBuff, 32);
Vous vous demandez peut-être à quoi sert la chaîne Content-Encoding: auth\0.
En bref, il n'a pas d'objectif clair, bien que les navigateurs puissent déchiffrer un message entrant et rechercher l'encodage de contenu attendu.
\0 ajoute un octet d'une valeur de 0 à la fin du tampon. C'est ce qu'attendent les navigateurs qui déchiffrent le message, qui s'attendent à un certain nombre d'octets pour l'encodage du contenu, suivis d'un octet de valeur 0, puis des données chiffrées.
Notre clé pseudo-aléatoire exécute simplement l'authentification, le secret partagé et une information d'encodage via HKDF (c'est-à-dire en la rendant plus forte sur le plan cryptographique).
Contexte
Le "contexte" est un ensemble d'octets utilisé pour calculer ultérieurement deux valeurs dans le navigateur de chiffrement. Il s'agit essentiellement d'un tableau d'octets contenant la clé publique de l'abonnement et la clé publique locale.
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,
]);
Le tampon de contexte final est un libellé, le nombre d'octets de la clé publique de l'abonnement, suivi de la clé elle-même, puis du nombre d'octets de la clé publique locale, suivi de la clé elle-même.
Cette valeur de contexte peut être utilisée pour créer un nonce et une clé de chiffrement de contenu (CEK).
Clé de chiffrement de contenu et nonce
Un nonce est une valeur qui empêche les attaques par rejeu, car il ne doit être utilisé qu'une seule fois.
La clé de chiffrement de contenu (CEK) est la clé qui sera finalement utilisée pour chiffrer notre charge utile.
Nous devons d'abord créer les octets de données pour le nonce et la CEK, qui sont simplement une chaîne d'encodage de contenu suivie du tampon de contexte que nous venons de calculer :
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]);
Ces informations sont transmises via HKDF en combinant le sel et la clé PRK avec nonceInfo et 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);
Nous obtenons ainsi notre nonce et notre clé de chiffrement de contenu.
Effectuer le chiffrement
Maintenant que nous disposons de notre clé de chiffrement de contenu, nous pouvons chiffrer la charge utile.
Nous créons un chiffrement AES128 en utilisant la clé de chiffrement de contenu comme clé et le nonce comme vecteur d'initialisation.
Dans Node, cela se fait comme suit :
const cipher = crypto.createCipheriv(
'id-aes128-GCM',
contentEncryptionKey,
nonce,
);
Avant de chiffrer notre charge utile, nous devons définir la quantité de marge que nous souhaitons ajouter au début de la charge utile. Nous souhaitons ajouter un remplissage pour éviter que des personnes malveillantes puissent déterminer les "types" de messages en fonction de la taille de la charge utile.
Vous devez ajouter deux octets de marge intérieure pour indiquer la longueur de toute marge intérieure supplémentaire.
Par exemple, si vous n'avez pas ajouté de marge intérieure, vous aurez deux octets avec la valeur 0, ce qui signifie qu'il n'y a pas de marge intérieure. Après ces deux octets, vous lirez la charge utile. Si vous avez ajouté 5 octets de marge intérieure, les deux premiers octets auront une valeur de 5. Le consommateur lira alors cinq octets supplémentaires, puis commencera à lire la charge utile.
const padding = new Buffer(2 + paddingLength);
// The buffer must be only zeros, except the length
padding.fill(0);
padding.writeUInt16BE(paddingLength, 0);
Nous exécutons ensuite notre marge intérieure et notre charge utile via ce chiffrement.
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()]);
Nous disposons maintenant de notre charge utile chiffrée. Super !
Il ne reste plus qu'à déterminer comment cette charge utile est envoyée au service push.
En-têtes et corps de la charge utile chiffrée
Pour envoyer cette charge utile chiffrée au service push, nous devons définir quelques en-têtes différents dans notre requête POST.
En-tête de chiffrement
L'en-tête "Encryption" doit contenir le salage utilisé pour chiffrer la charge utile.
Le sel de 16 octets doit être encodé en base64 de manière sécurisée pour les URL et ajouté à l'en-tête Encryption, comme suit :
Encryption: salt=[URL Safe Base64 Encoded Salt]
En-tête Crypto-Key
Nous avons vu que l'en-tête Crypto-Key est utilisé dans la section "Clés du serveur d'application" pour contenir la clé publique du serveur d'application.
Cet en-tête permet également de partager la clé publique locale utilisée pour chiffrer la charge utile.
L'en-tête obtenu se présente comme suit :
Crypto-Key: dh=[URL Safe Base64 Encoded Local Public Key String]; p256ecdsa=[URL Safe Base64 Encoded Public Application Server Key]
En-têtes de type, de longueur et d'encodage de contenu
L'en-tête Content-Length correspond au nombre d'octets de la charge utile chiffrée. Les en-têtes "Content-Type" et "Content-Encoding" sont des valeurs fixes.
comme illustré ci-dessous.
Content-Length: [Number of Bytes in Encrypted Payload]
Content-Type: 'application/octet-stream'
Content-Encoding: 'aesgcm'
Une fois ces en-têtes définis, nous devons envoyer la charge utile chiffrée en tant que corps de notre requête. Notez que Content-Type est défini sur application/octet-stream. En effet, la charge utile chiffrée doit être envoyée sous la forme d'un flux d'octets.
Dans NodeJS, nous procéderions comme suit :
const pushRequest = https.request(httpsOptions, function(pushResponse) {
pushRequest.write(encryptedPayload);
pushRequest.end();
D'autres en-têtes ?
Nous avons abordé les en-têtes utilisés pour les clés JWT/de serveur d'application (c'est-à-dire comment identifier l'application auprès du service push) et ceux utilisés pour envoyer une charge utile chiffrée.
Les services push utilisent des en-têtes supplémentaires pour modifier le comportement des messages envoyés. Certains de ces en-têtes sont obligatoires, tandis que d'autres sont facultatifs.
En-tête TTL
Obligatoire
TTL (ou "durée de vie") est un entier spécifiant le nombre de secondes pendant lesquelles vous souhaitez que votre message push reste sur le service push avant d'être distribué. Lorsque le TTL expire, le message est supprimé de la file d'attente du service push et n'est pas distribué.
TTL: [Time to live in seconds]
Si vous définissez un TTL de zéro, le service push tentera d'envoyer le message immédiatement, mais si l'appareil n'est pas accessible, votre message sera immédiatement supprimé de la file d'attente du service push.
Techniquement, un service push peut réduire la valeur TTL d'un message push s'il le souhaite. Pour savoir si cela s'est produit, examinez l'en-tête TTL dans la réponse d'un service push.
Sujet
Optional
Les sujets sont des chaînes qui peuvent être utilisées pour remplacer un message en attente par un nouveau message s'ils ont des noms de sujet correspondants.
Cela est utile lorsque plusieurs messages sont envoyés alors qu'un appareil est hors connexion, et que vous souhaitez que l'utilisateur ne voie que le dernier message lorsque l'appareil est allumé.
Urgence
Optional
L'urgence indique au service push l'importance d'un message pour l'utilisateur. Le service push peut l'utiliser pour préserver l'autonomie de la batterie de l'appareil d'un utilisateur en ne le réveillant que pour les messages importants lorsque la batterie est faible.
La valeur de l'en-tête est définie comme indiqué ci-dessous. La valeur par défaut est normal.
Urgency: [very-low | low | normal | high]
Tout au même endroit
Si vous avez d'autres questions sur le fonctionnement de tout cela, vous pouvez toujours voir comment les bibliothèques déclenchent des messages push sur l'organisation web-push-libs.
Une fois que vous disposez d'une charge utile chiffrée et des en-têtes ci-dessus, il vous suffit d'envoyer une requête POST à endpoint dans un PushSubscription.
Que faisons-nous de la réponse à cette requête POST ?
Réponse du service push
Une fois que vous avez envoyé une requête à un service push, vous devez vérifier le code d'état de la réponse, car il vous indiquera si la requête a abouti ou non.
| Code d'état | Description |
|---|---|
| 201 | Création terminée La demande d'envoi d'un message push a été reçue et acceptée. |
| 429 | Trop de requêtes. Cela signifie que votre serveur d'applications a atteint une limite de débit avec un service push. Le service push doit inclure un en-tête "Retry-After" pour indiquer le délai avant qu'une autre requête puisse être effectuée. |
| 400 | Demande incorrecte. Cela signifie généralement que l'un de vos en-têtes n'est pas valide ou est mal formaté. |
| 404 | Introuvable. Cela indique que l'abonnement a expiré et ne peut pas être utilisé. Dans ce cas, vous devez supprimer l'objet "PushSubscription" et attendre que le client réabonne l'utilisateur. |
| 410 | Supprimée définitivement. L'abonnement n'est plus valide et doit être supprimé du serveur d'application. Pour reproduire ce problème, appelez "unsubscribe()" sur un "PushSubscription". |
| 413 | La taille de la charge utile est trop importante. La taille minimale de la charge utile qu'un service push doit accepter est de 4 096 octets (ou 4 Ko). |
Pour en savoir plus sur les codes d'état HTTP, vous pouvez également consulter la norme Web Push (RFC8030).
Étapes suivantes
- Présentation des notifications push Web
- Fonctionnement de la méthode push
- Abonner un utilisateur
- Expérience utilisateur liée aux autorisations
- Envoyer des messages avec les bibliothèques Web Push
- Protocole Web Push
- Gérer les événements push
- Afficher une notification
- Comportement des notifications
- Modèles de notification courants
- Questions fréquentes sur les notifications push
- Problèmes courants et signalement de bugs