Notifications sur l'appareil des membres - #37
Merged
Conversation
Un message envoyé depuis « Notifications » arrive sur le téléphone ou l'ordinateur des membres visés, même site fermé, via les notifications web du navigateur. Rien à configurer : la paire de clés VAPID est engendrée au premier abonnement et conservée chiffrée, comme les autres secrets de l'application. L'écriture n'a lieu que si la colonne est vide, si bien que deux abonnements simultanés sur une installation neuve retiennent la même paire. Chaque membre garde la main, à deux niveaux volontairement distincts. Un interrupteur sur son compte coupe tout, partout ; l'activation, elle, se fait appareil par appareil, puisque le navigateur exige une autorisation explicite et qu'on peut vouloir être prévenu sur son téléphone mais pas sur l'ordinateur familial. Le choix du membre prime sur celui de l'expéditeur : un membre qui a coupé ne reçoit rien, même nommément visé. L'écran d'envoi dit qui est joignable avant d'écrire, et l'historique dit ce qu'il est advenu de chaque envoi, appareil par appareil. « Transmise » signifie que le service du navigateur a pris le message en charge — ce qui ne prouve rien de l'appareil. « Reçue » et « Ouverte » viennent du service worker lui-même, qui accuse réception puis ouverture ; c'est la seule façon honnête de répondre à « qui l'a reçu ». L'accusé s'authentifie par un jeton propre à l'envoi, glissé dans la charge utile : une notification peut arriver longtemps après une déconnexion. Un abonnement révoqué par le navigateur (404 ou 410) est retiré sur-le-champ, sans quoi il échouerait à chaque envoi. Vérifié sur une instance réelle, avec un faux service de notification en HTTPS et de vraies clés de chiffrement : charge utile chiffrée et en-tête VAPID présents, deux appareils servis pour un même membre, membre ayant coupé écarté, abonnement périmé retiré après un 410, accusés de réception et d'ouverture enregistrés sans session, accusé tardif qui ne rétrograde pas une ouverture, jeton inconnu sans effet, et les deux écrans conformes dans un navigateur. Corrige au passage un défaut trouvé par ce test : le contact VAPID était transmis tel quel, or seules les adresses `mailto:` et `https:` sont acceptées — une instance sans e-mail de contact n'aurait rien pu envoyer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014SfQYBU4xXTeSEHKhHQXdD
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Un message envoyé depuis Notifications arrive sur le téléphone ou l'ordinateur des membres visés, même site fermé.
Rien à configurer
La paire de clés VAPID est engendrée au premier abonnement et conservée chiffrée, comme les autres secrets. L'écriture n'a lieu que si la colonne est vide : deux abonnements simultanés sur une installation neuve retiennent la même paire.
Le membre garde la main, à deux niveaux
Le choix du membre prime sur celui de l'expéditeur : un membre qui a coupé ne reçoit rien, même nommément visé.
Qui l'a reçu
L'écran d'envoi dit qui est joignable avant d'écrire — « 3 appareils », « aucun appareil activé », « a coupé les notifications ». L'historique dit ensuite ce qu'il est advenu de chaque envoi, appareil par appareil :
« Reçue » et « Ouverte » viennent du service worker lui-même : c'est la seule façon honnête de répondre à la question. L'accusé s'authentifie par un jeton propre à l'envoi glissé dans la charge utile — une notification peut arriver longtemps après une déconnexion, et exiger une session la perdrait.
Un abonnement révoqué par le navigateur (404/410) est retiré sur-le-champ.
Vérifications
Instance réelle, faux service de notification en HTTPS, vraies clés de chiffrement :
AuthorizationprésentdisabledDéfaut trouvé par ce test et corrigé : le contact VAPID était transmis tel quel, or seules les adresses
mailto:ethttps:sont acceptées — une instance sans e-mail de contact n'aurait rien pu envoyer.Ajoute la dépendance
web-push, un manifeste d'application (condition posée par iOS pour recevoir des notifications) et un service worker qui ne met rien en cache.tsc --noEmit,npm run lintetnext buildpassent.Generated by Claude Code