Hallo @featheredtoast, ich bin auch neugierig darauf. Meinst du, dass Desktop-Web-Push-Benachrichtigungen keinen Drittanbieter-Vermittler wie GCM, FCM oder APNs verwenden, sondern dass die Benachrichtigungsnachrichten stattdessen von deinem eigenen Endpunkt ausgehen – der mit Redis oder etwas Ähnlichem verbunden ist – und dass nur mobile Push-Benachrichtigungen solche Drittanbieter-Vermittler nutzen?
Kurz gesagt: Nein. Push-Benachrichtigungen werden über die eigenen Browser-Integrationen bereitgestellt, sodass kein Drittanbieter-Vermittler beteiligt ist.
Technisch gesehen gibt es einen Server (irgendwo, nicht auf Ihrem Discourse-Server), der für die Zustellung von Nachrichten an Ihr Gerät verantwortlich ist. Unsere Implementierung wird von allen Browsern unterstützt, die VAPID implementieren (Sending VAPID identified WebPush Notifications via Mozilla’s Push Service | Mozilla Services). Die VAPID-Server des Browserherstellers sind die Server, die die Daten tatsächlich an Ihr Gerät pushen.
Entschuldigt bitte, dass ich das Thema wieder aufgreife, aber meine Suche hat mich hierher geführt und ich bin mir nicht sicher, ob es damit zusammenhängt.
Unsere /logs sind voll mit:
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'
Wir sehen Tausende dieser Fehlermeldungen. Ist das… normal?
Das klingt nach einem Fehler. Nicht übereinstimmende Absender-IDs sollten den Client automatisch abmelden, aber es scheint einen Fehler bei der Erkennung der Fehlermeldung von FCM zu geben.
Definitiv keine Angelegenheit für Endanwender, aber ja, dieser Lärm sollte nicht vorhanden sein.
Ich vermute, wir sollten die Ausnahmen Webpush::InvalidSubscription und Webpush::Unauthorized behandeln, indem wir die Abmeldung vornehmen. Anscheinend gab es sie nicht, als wir zuletzt die Fehlerbehandlung für Push-Benachrichtigungen aktualisiert haben.
Wie ich bereits erwähnt habe, erhalten wir dies zu Tausenden:
Ich habe dies bereits hier gemeldet, falls Sie diesen Beitrag thematisch passend halten möchten. Sie können ihn gerne zusammenführen, löschen oder anderweitig bearbeiten.
