Bonjour @featheredtoast, je suis moi aussi curieux à ce sujet. Voulez-vous dire que les notifications push web sur ordinateur n’utilisent aucun intermédiaire tiers comme GCM, FCM ou APNs, et que, au contraire, les messages de notification proviennent de votre propre point de terminaison — connecté à Redis ou quelque chose de similaire —, et que seules les notifications push mobiles font appel à de tels intermédiaires tiers ?
En bref, non. Les notifications push sont gérées par les intégrations natives du navigateur, si bien qu’aucun intermédiaire tiers n’est impliqué.
Techniquement, il existe un serveur (quelque part, mais pas votre serveur Discourse) chargé de livrer les messages à votre appareil. Notre implémentation est prise en charge par tous les navigateurs qui implémentent VAPID (Sending VAPID identified WebPush Notifications via Mozilla’s Push Service | Mozilla Services). Les serveurs VAPID du fournisseur du navigateur sont ceux qui envoient réellement les données à votre appareil.
Désolé de ressasser cela, mais mes recherches m’ont mené ici et je ne suis pas sûr que cela soit lié.
Nos /logs sont remplis du message suivant :
Failed to send push notification : host: fcm.googleapis.com, #<Net::HTTPForbidden 403 Forbidden readbody=true> body: the key in the authorization header does not correspond to the sender ID used to subscribe this user. Please ensure you are using the correct sender ID and server Key from the Firebase console.
Backtrace
webpush-1.1.0/lib/webpush/request.rb:175:in `verify_response'
webpush-1.1.0/lib/webpush/request.rb:34:in `perform'
webpush-1.1.0/lib/webpush.rb:44:in `payload_send'
/var/www/discourse/app/services/push_notification_pusher.rb:79:in `send_notification'
/var/www/discourse/app/services/push_notification_pusher.rb:25:in `block in push'
activerecord-6.0.3.3/lib/active_record/relation/delegation.rb:87:in `each'
activerecord-6.0.3.3/lib/active_record/relation/delegation.rb:87:in `each'
/var/www/discourse/app/services/push_notification_pusher.rb:23:in `push'
/var/www/discourse/app/jobs/regular/send_push_notification.rb:7:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'
sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread'
Nous en voyons des milliers. Est-ce… normal ?
Cela ressemble à un bug : les IDs d’expéditeur non correspondants devraient automatiquement désabonner le client, mais il semble y avoir un bug quelque part dans la détection du message d’erreur provenant de FCM.
Ce n’est absolument pas quelque chose qui concerne les clients, mais oui, c’est du bruit qui ne devrait pas être là.
Je suppose que nous devrions gérer les exceptions Webpush::InvalidSubscription et Webpush::Unauthorized en désabonnant. Il semble qu’elles n’existaient pas lors de notre dernière mise à jour de la gestion des erreurs pour les notifications push.
Comme je l’ai mentionné, nous en recevons des milliers :
J’avais précédemment signalé cela ici au cas où vous souhaiteriez garder celui-ci sur le sujet. N’hésitez pas à fusionner, supprimer, etc.