Hello @featheredtoast, I am also curious about this. Do you mean that desktop web push notifications make no use of a third-party broker such as GCM or FCM or APNs, and that, instead, notification messages originate from your own endpoint – wired to redis or something --, and that only mobile push notifications make use of such third-party brokers?
Short answer, no, push notifications are provided by the browser’s own integrations, so no 3rd party broker is involved.
Technically, there is a server (somewhere, not your Discourse server) that is responsible for delivering messages to your device – our implementation is supported by all browsers that implement VAPID (Sending VAPID identified WebPush Notifications via Mozilla’s Push Service | Mozilla Services). The browser vendor’s VAPID servers are the servers that actually push out the data to your device.
6 Likes
Sorry for rehashing this, but my searches lead me here and I’m not sure if its related.
Our /logs are filled with the:
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'
We are seeing thousands of these. Is this… normal?
1 Like
Sounds like a bug, mismatched sender IDs should auto-unsubscribe that client, but it sounds like there’s a bug somewhere when detecting the error message from fcm.
Definitely not a client-facing thing, but yeah this is noise that shouldn’t be there.
4 Likes
I guess we should handle the Webpush::InvalidSubscription and Webpush::Unauthorized exceptions by unsubscribing. Looks like they didn’t exist when we last updated the error handling for push notifications.
4 Likes
As I mentioned, we get this by the thousands:
I had previously reported this here in case you want to keep this one on-topic. Feel free to merge/delete/etc.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.