¿Las notificaciones push usan intermediarios de terceros?

Hola @featheredtoast, también tengo curiosidad sobre esto. ¿Quieres decir que las notificaciones push web de escritorio no utilizan un intermediario de terceros como GCM, FCM o APNs, y que, en su lugar, los mensajes de notificación se originan en tu propio punto final (conectado a Redis o algo similar), y que solo las notificaciones push móviles utilizan dichos intermediarios de terceros?

Respuesta corta: no. Las notificaciones push las proporciona el propio navegador mediante sus integraciones, por lo que no interviene ningún intermediario de terceros.

Técnicamente, existe un servidor (en algún lugar, no en tu servidor de Discourse) responsable de entregar los mensajes a tu dispositivo. Nuestra implementación es compatible con todos los navegadores que implementan VAPID (Sending VAPID identified WebPush Notifications via Mozilla’s Push Service | Mozilla Services). Los servidores VAPID del proveedor del navegador son los que realmente envían los datos a tu dispositivo.

Perdona por volver sobre esto, pero mis búsquedas me han llevado aquí y no estoy seguro de si está relacionado.

Nuestros /logs están llenos de:

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'

Estamos viendo miles de estos mensajes. ¿Es esto… normal?

Parece un error: las IDs de remitente que no coinciden deberían cancelar automáticamente la suscripción de ese cliente, pero parece que hay un fallo en algún lugar al detectar el mensaje de error de FCM.

Definitivamente no es algo que deba verse por parte del cliente, pero sí, es un ruido que no debería estar ahí.

Supongo que deberíamos manejar las excepciones Webpush::InvalidSubscription y Webpush::Unauthorized cancelando la suscripción. Parece que no existían la última vez que actualizamos el manejo de errores para las notificaciones push.

Como mencioné, recibimos esto por miles:

Ya había reportado esto aquí por si prefieres mantener este hilo centrado en el tema. Siéntete libre de fusionarlo, eliminarlo, etc.