Dernièrement, j'ai travaillé sur un nouveau package webpush construit à partir de zéro en utilisant uniquement des API Web. Cela permet (au moins en théorie) d'envoyer des messages Web Push directement depuis votre navigateur.

Ce billet de blog a pour objectif d'expliquer ce qu'est le protocole Web Push, comment il fonctionne
(RFC 8291) et comment envoyer des messages Web Push à l'aide de ma bibliothèque.

Qu'est-ce que le protocole Web Push ?

Le protocole Web Push est un protocole intermédiaire qui permet à une application d'envoyer des messages à un agent utilisateur (un navigateur généralement).

Il est similaire aux événements envoyés par le serveur (SSE) dans le sens où les messages sont transmis à l'agent utilisateur, mais il sert un objectif différent. Les messages Web Push ne nécessitent pas que les sites Web aient un onglet ouvert en tant que techniciens de service
peut écouter les messages push. Cela fonctionne en arrière-plan.

Comment fonctionne le protocole Web Push ?

Le protocole Web Push implique trois acteurs :

• User-Agent : le navigateur des visiteurs de votre site Web en général
• Service Push : serveur push maintenu et détenu par Google, Mozilla ou Apple selon le navigateur
• Serveur d'applications : votre serveur

Voici un aperçu des interactions entre eux :

     -------             --------------         ------------- 
    |  UA   |           | Push Service |       | Application |
     -------             --------------         ------------- 
        |                      |                      |
        |        Setup         |                      |
        ||                      |
        |           Provide Subscription              |
        |-------------------------------------------->|
        |                      |                      |
        :                      :                      :
        |                      |     Push Message     |
        |    Push Message      |



Un service push intermédiaire est requis pour plusieurs raisons.

Premièrement, cela réduit l'utilisation de la bande passante et de la batterie, car les agents utilisateurs ne maintiennent qu'une seule connexion pour tous les sites Web au lieu d'une par site Web.

Il améliore également l'évolutivité et la fiabilité, car les services push des principaux navigateurs sont conçus pour gérer des millions d'utilisateurs. Étant donné que les messages push doivent être conservés si l'agent utilisateur est hors ligne, la création d'un service push nécessite beaucoup d'ingénierie, une infrastructure résiliente et redondante

Enfin, la création, le déploiement et la maintenance d'un service push personnalisé sont souvent trop complexes et gourmands en ressources pour les petites entreprises Web. Cela donnerait aux grandes entreprises un avantage concurrentiel injuste, car elles disposeraient des ressources nécessaires pour développer et affiner leurs propres services push.

Si vous êtes un utilisateur soucieux de la confidentialité comme moi, vous voyez un service intermédiaire

la réception de tous les messages déclenche des signaux d’alarme. Pour répondre à ce problème, Web Push

les messages sont sécurisés via le codage de contenu crypté HTTP (voir mon 

paquet http-ece), garantissant que

les informations sensibles restent protégées et illisibles pour tout tiers

services en transit.

  
  
  Installation


Vous avez peut-être remarqué que la flèche de configuration est différente des autres dans le graphique ASCII ci-dessus. En effet, la phase de configuration dépend de la mise en œuvre. Tous les principaux navigateurs implémentent le javascript

Pousser l'API dans un

autrement. Une méthode PushManager.subscribe() qui renvoie un standard

PushSubscription est exposé.

Les abonnements contiennent toujours un point de terminaison d'URL unique associé à l'abonnement push et une clé publique utilisée pour chiffrer les messages.

Lors de la création d'un abonnement, une applicationServerKey facultative peut être fournie pour identifier les messages envoyés par le serveur d'applications. Il s'agit de la méthode d'authentification VAPID (Voluntary Application Server Identification)

(RFC8292). Les clés VAPID sont utilisées pour atténuer les attaques DDOS sur les services push. L'ajout d'une authentification entre le serveur d'applications et le service push réduit également les risques de fuite du point de terminaison d'abonnement. Pour ces raisons, ils sont obligatoires dans Firefox.

  
  
  Fournir un abonnement


La deuxième étape consiste à envoyer l'abonnement au serveur d'applications afin qu'il puisse commencer à envoyer des messages.

Le serveur d'applications stocke généralement l'abonnement dans une base de données pour une réutilisation ultérieure.

  
  
  Message poussé


Enfin, pour envoyer un message, le serveur d'applications envoie une requête HTTP cryptée avec un schéma d'authentification insipide si applicationServerKey a été fournie pour créer l'abonnement.

Si l'agent utilisateur est en ligne lorsque le message est reçu par le service push, il l'est

transmis. Sinon, il est stocké jusqu'à ce que l'agent utilisateur soit en ligne ou que le message expire.

Lorsque l'agent utilisateur reçoit un message, il exécute le gestionnaire d'événements push qui est principalement utilisé pour afficher une notification et c'est tout.

  
  
  Configuration d'un serveur d'applications à l'aide de webpush


Vous devez d'abord générer des clés VAPID car certains navigateurs les rendent obligatoires :



$ deno run https://raw.githubusercontent.com/negrel/webpush/master/cmd/generate-vapid-keys.ts




Copiez la sortie et enregistrez-la dans un fichier, vous n'avez pas besoin de générer à nouveau les clés VAPID.

Dans le code de votre serveur d'applications, vous pouvez les charger comme suit :



import * as webpush from "jsr:@negrel/webpush";

// Read generated VAPID file.
const vapidKeysJson = Deno.readTextFileSync("./path/to/vapid.json");

// Import VAPID keys.
webpush.importVapidKeys(JSON.parse(vapidKeysJson));




Ensuite, vous devrez créer une instance d'objet ApplicationServer.



// adminEmail is used by Push services maintainer to contact you in case there
// is problem with your application server.
const adminEmail = "[email protected]";

// Create an application server object.
const appServer = await webpush.ApplicationServer.new({
  contactInformation: "mailto:"   adminEmail,
  vapidKeys,
});




Ensuite, pour envoyer des messages push, créez simplement un PushSubscriber et appelez son

méthode pushMessage()/pushTextMessage() comme suit :



const subsribers = [];

// HTTP handler for user agent sending their subscription.
function subscribeHandler(req) {
  // Extract subscription send by user agent.
  const subscription = await req.json();

  // Store subscription in db.
  // ...

  // Create a subscriber object.
  const sub = appServer.subscribe(subscription);

  // Store subscriber in memory.
  subscribers.push(sub);
}

// Helper method to send message to all subscribers.
function broadcastMessage(msg) {
  for (const sub of subscribes) {
    sub.pushTextMessage(msg, {});
  }
}




Ça y est, vous envoyez des messages push à vos abonnés !

le référentiel webpush contient un exemple interactif avec un code similaire que vous pouvez exécuter localement. Il contient également du code javascript côté client, alors assurez-vous de le consulter !