Produits Entr'ouvert » Combo

Voilà ma proposition décomposée en 6 patchs.

• 1er commit "paramétrage" : configurez PUSH_NOTIFICATIONS_SETTINGS avec les instructions dans settings.py pour générer ses propres clés VAPID. À noter que la dépendance vers django-push-notification ne peut pas être mise dans setup.py ou le requirements.txt car elle est incompatible avec Django<1.11.
• 2e commit "modèles" : les modèles dans combo.apps.pwa.models, dont une cellule Combo bien à part pour l'interface d'autorisation du Push, et la migration qu'il faut
• 3e commit "vues" : les urls pour s'abonner, et celle pour "ack" ou "forget" la notification qui présente des actions. Le service-worker unique, et le webpush.js qui est le controlleur injecté par la cellule combo WebPushCell.
• 4e "send_webpush" : la commande de management, sa fonction utilitaire, et la modif du cron.hourly
  • Pour tester, créez une notification dans l'admin (cf. ci-dessous), puis insérez la cellule Combo WebPush dans une page et abonnez vous, la commande suivante va envoyer toutes les notifications pas encore envoyées, et qui ont moins de 24h depuis leur création.
    

    $ combo-manage tenant_command send_webpush --all-tenants
    

• 5e "test": un test de la commande send_webpush
• 6e commit "admin": pour le debug et le test, c'est pratique d'avoir les modèles dans l'admin django : crez

La capture montre une notification reçue avec chromium (en bas à droite). L'action OK va "ack sur le modèle Notification associé, et tout clic va ouvrir ou "focus" sur l'URL de Notification.url

La seule impasse faite par rapport est la fin du second point de Fred dans son commentaire 12 : celle de l'enregistrement du nombre d'essais et timestamp d'envoie des requêtes en erreur au service de push (google, ff, etc) car je préfère passer cette option pour le moment au profit d'un log du statut des envois dans le modèle WebPushRecord. Cela alourdirait pas mal le code, or on ne sait pas pour le moment si c'est nécessaire dans le cadre de l'utilisation du push avec les donneées de combo.apps.notifications.

Elias Showk a écrit :

Voilà ma proposition décomposée en 6 patchs.

• et un 7e patch pour publik-base-theme pour simplement gérer le style de la cellule combo "webpush"

Elias Showk a écrit :

Elias Showk a écrit :

Voilà ma proposition décomposée en 6 patchs.

• Voilà une correction du patch 0005 pour les tests (suivre le résultat ici https://jenkins2.entrouvert.org/job/combo-wip/)

Branche wip/25462-pwa-push avec le minimum nécessaire.

• dépendance directe sur pywebpush, on évite django-push-notifications et la série de dépendances supplémentaires qui viendraient avec, on évite aussi ses modèles pas nécessairement adaptés et plus généralement ça permet de rester à un niveau sans trop d'abstractions compliquées à justifier.

Les notifications push, comment ça marche ?

Alors premier point, on peut oublier le "notification" de la question pour le moment, s'intéresser uniquement à "push".

Il s'agit donc d'un mécanisme permettant à un navigateur^Wsite de recevoir des données sans rien avoir demandé.

Comment ça marche ? D'une manière ou d'une autre le navigateur polle un serveur de notifications, s'il y en a une pour lui, il la prend, "réveille" le site, lui file la donnée.

On a donc trois morceaux : le navigateur, le serveur de notifications et le site django.

Le site django est configuré avec une paire de clés "VAPID"; il y a un python-vapid pour générer ça mais bête et méchant, ça se fait avec openssl.

openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem
openssl ec -in vapid_private.pem -pubout -out vapid_public.pem
openssl ec -in vapid_private.pem -outform DER|tail -c +8|head -c 32|base64|tr -d '=' |tr '/+' '_-' > private_key.txt
openssl ec -in vapid_private.pem -pubout -outform DER|tail -c 65|base64|tr -d '=' |tr '/+' '_-' > public_key.txt

(lignes de https://mushfiq.me/2017/09/25/web-push-notification-using-python/, no comment, toujours bien qu'un outil qui ne marche pas)

Clé publique clé privée ça va dans la config django,

PWA_VAPID_PUBLIK_KEY = "BFzvUdXB-HLKQV1mYEtmIOaSYkVdit-qLgoWpfmfQjQUlpAfnd37GyRHXRRKJ7iTTFOjXjiChtAGbcF8b7_mXRQ" 
PWA_VAPID_PRIVATE_KEY = "..." 

Il y a aussi une notion de "claims", va savoir, on en a aussi besoin, hop dans la config :

PWA_VAPID_CLAIMS = {'sub': 'mailto:admin@entrouvert.com'}

Le site ainsi configuré, direction le navigateur.

L'usager manifeste son envie de recevoir des notifications. Il y a appel à combo_pwa_subscribe_user. (ce patch expose cette fonction, mais rien qui ne l'appelle, c'est présent côté toodego).

Cet appel abonne l'usager :

  swRegistration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: applicationServerKey
  }).then(...)

En résultat on obtient un objet PushSubscription et vite fait on l'envoie côté django pour l'enregistrer :

function combo_pwa_update_subscription_on_server(subscription) {
  $.ajax({
       url: '{% url "pwa-subscribe-push" %}',
       data: JSON.stringify(subscription),

On a donc côté django une table avec identifiant usager / blob ~opaque d'abonnement.

C'en est fini pour le navigateur, on regarde côté django.

Il y aurait des trucs à faire évoluer côté notification, recevoir des paramètres, gérer des priorités, etc. mais en l'état, au plus simple, signal post_save, et à la création d'une notif, on arrive ainsi dans combo.apps.pwa.signals.

Là, on a l'utilisateur (notification.user), on itère sur tous les abonnements push de cet utilisateur, et pour chacun d'eux, on webpush :

    for subscription in PushSubscription.objects.filter(user_id=instance.user_id):
        pywebpush.webpush(
                subscription_info=subscription.subscription_info,
                data=message,
                vapid_private_key=settings.PWA_VAPID_PRIVATE_KEY,
                vapid_claims=settings.PWA_VAPID_CLAIMS
                )

Ça chiffre ça signe que sais-je et c'est envoyé au serveur de notifications (dont l'url est dans le subscription_info) (et donc, Google).

Revient le navigateur qui continuait à poller le serveur de notifications et qui voit un truc pour lui, le prend et le passe au site, qui l'attrape au vol :

self.addEventListener('push', event => {

Dans event, il y a data, c'est le data=message de l'appel à pywebpush. On parse le json, on en sort les paramètres de la notif et hop, on en demande l'affichage :

  self.registration.showNotification(title, options))

Et ça s'affiche, tout le monde est content, etc.

Donc, dans la branche, d'abord un commit qui prend le code d'enregistrement du service worker, qui était dans publik-base-theme, et le tape côté combo.

Puis un commit qui fait tout le brol raconté ici.

Il manque juste le try/except dans le signal autour de pywebpush, sinon c'est ok.

try/except ajouté, merci.

commit e039b655e1aa4c66c43e61b945f3e4e0685ec349
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Nov 26 17:14:05 2018 +0100

    pwa: add basic support for push notifications (#25462)

commit 88baf45c715c4c98bffeb3b90c778294c1f465da
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Nov 26 15:46:38 2018 +0100

    pwa: add service worker registration script (#25462)