Olá @featheredtoast, também estou curioso sobre isso. Você quer dizer que as notificações push da web para desktop não utilizam um broker de terceiros, como GCM, FCM ou APNs, e que, em vez disso, as mensagens de notificação originam-se de seu próprio endpoint — conectado ao Redis ou algo similar —, e que apenas as notificações push móveis utilizam esses brokers de terceiros?
Resposta curta: não. As notificações push são fornecidas pelas próprias integrações do navegador, portanto, nenhum intermediário de terceiros está envolvido.
Tecnicamente, há um servidor (em algum lugar, não no seu servidor Discourse) responsável por entregar as mensagens ao seu dispositivo — nossa implementação é compatível com todos os navegadores que implementam o VAPID (Sending VAPID identified WebPush Notifications via Mozilla’s Push Service | Mozilla Services). Os servidores VAPID dos fabricantes dos navegadores são os que realmente enviam os dados para o seu dispositivo.
Desculpe reviver isso, mas minhas buscas me levaram aqui e não tenho certeza se está relacionado.
Nossos /logs estão cheios 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 vendo milhares desses. Isso é… normal?
Parece ser um bug: IDs de remetente incompatíveis deveriam cancelar automaticamente a assinatura desse cliente, mas parece haver um erro em algum lugar ao detectar a mensagem de erro do FCM.
Definitivamente não é algo voltado ao cliente, mas sim, isso é ruído que não deveria estar aqui.
Acho que devemos tratar as exceções Webpush::InvalidSubscription e Webpush::Unauthorized cancelando a inscrição. Parece que elas não existiam quando atualizamos pela última vez o tratamento de erros para notificações push.
Como mencionei, recebemos isso aos milhares:
Já havia relatado isso aqui, caso queira manter este tópico focado no assunto. Sinta-se à vontade para mesclar, excluir, etc.