[PR #3792] [MERGED] register missing push devices at login #22868

New Issue

GiteaMirror · 2026-05-16T05:36:32-05:00

GiteaMirror commented

2026-05-16 05:36:32 -05:00

📋 Pull Request Information

Original PR: https://github.com/dani-garcia/vaultwarden/pull/3792
Author: @stefan0xC
Created: 8/22/2023
Status: ✅ Merged
Merged: 1/30/2024
Merged by: @dani-garcia

Base: main ← Head: register-push-token

📝 Commits (1)

6f28af7 register missing push devices at login

📊 Changes

5 files changed (+60 additions, -21 deletions)

View changed files

📝 src/api/admin.rs (+1 -1)
📝 src/api/core/accounts.rs (+18 -11)
📝 src/api/identity.rs (+4 -0)
📝 src/api/push.rs (+28 -9)
📝 src/db/models/device.rs (+9 -0)

📄 Description

I've been looking into why enabling push notifications is not enough to get automatic sync to work and why it requires removing the app (or clearing the app data) and as far as I understand this deep dive that is because the endpoint on vaultwarden that registers the token to Bitwarden's Azure Notification Hub is currently only called when the OnNewToken() method is run. (Which only happens in rare instances, i.e. when installing the app or clearing the app data.)

If we save the push_token even when PUSH_ENABLED=false we could register missing push devices later. I've implemented a crude way of doing it (looking for a user's not yet registered devices on login, once mobile push notifications are enabled).

The push_uuid of a device will only be filled when push is enabled, so we know which push devices have not been registered yet.

Note: I'm not sure if there's a way to register the wrong token (which is why I'm skipping devices that have been added before this patch - and also because I don't know what values would be acceptable here). According to the deep dive the mobile clients (both on Android and iOS) should check daily if their token are still correct and will update them if not but I'm not sure what exactly happens in that case. - I'm currently testing what happens if you register the wrong token (if it will start working after 24 hours or if it will keep being broken). If this does not work this whole approach would probably not be viable.

Also since I don't know the API limits of the Bitwarden push relay and I did not want to abuse it (and maybe there's a better way to call the method) I've limited the number of devices that would be processed to <= 2. I think we could probably improve this a bit but I wanted to get some feedback first if this would be a viable approach. (Instead of calling it on login of a user it migh be better to do that on startup for all unregistered devices. Not really sure what is preferable here...)

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/dani-garcia/vaultwarden/pull/3792 **Author:** [@stefan0xC](https://github.com/stefan0xC) **Created:** 8/22/2023 **Status:** ✅ Merged **Merged:** 1/30/2024 **Merged by:** [@dani-garcia](https://github.com/dani-garcia) **Base:** `main` ← **Head:** `register-push-token` --- ### 📝 Commits (1) - [`6f28af7`](https://github.com/dani-garcia/vaultwarden/commit/6f28af72027b78e1d98e3fd16c333741928b52e8) register missing push devices at login ### 📊 Changes **5 files changed** (+60 additions, -21 deletions) <details> <summary>View changed files</summary> 📝 `src/api/admin.rs` (+1 -1) 📝 `src/api/core/accounts.rs` (+18 -11) 📝 `src/api/identity.rs` (+4 -0) 📝 `src/api/push.rs` (+28 -9) 📝 `src/db/models/device.rs` (+9 -0) </details> ### 📄 Description I've been looking into why enabling push notifications is not enough to get automatic sync to work and why it requires removing the app (or clearing the app data) and as far as I understand [this deep dive](https://contributing.bitwarden.com/architecture/deep-dives/push-notifications/mobile/) that is because the endpoint on vaultwarden that registers the token to Bitwarden's Azure Notification Hub is currently only called when the [`OnNewToken()`](https://github.com/bitwarden/mobile/blob/e274c0410749a8c87ec35abce47b9e58bf3ce43c/src/Android/Push/FirebaseMessagingService.cs#L19C39-L19C39) method is run. (Which only happens in rare instances, i.e. when installing the app or clearing the app data.) If we save the `push_token` even when `PUSH_ENABLED=false` we could register missing push devices later. I've implemented a crude way of doing it (looking for a user's not yet registered devices on login, once mobile push notifications are enabled). The `push_uuid` of a device will only be filled when push is enabled, so we know which push devices have not been registered yet. Note: I'm not sure if there's a way to register the wrong token (which is why I'm skipping devices that have been added before this patch - and also because I don't know what values would be acceptable here). According to the deep dive the mobile clients (both on Android and iOS) should check [daily](https://github.com/bitwarden/mobile/blob/249406e3a8c43624736696dbd4da19987aef9388/src/App/Pages/Vault/GroupingsPage/GroupingsPage.xaml.cs#L182-L185) if their token are still correct and will update them if not but I'm not sure what exactly happens in that case. - I'm currently testing what happens if you register the wrong token (if it will start working after 24 hours or if it will keep being broken). If this does not work this whole approach would probably not be viable. Also since I don't know the API limits of the Bitwarden push relay and I did not want to abuse it (and maybe there's a better way to call the method) I've limited the number of devices that would be processed to `<= 2`. I think we could probably improve this a bit but I wanted to get some feedback first if this would be a viable approach. (Instead of calling it on login of a user it migh be better to do that on startup for all unregistered devices. Not really sure what is preferable here...) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-05-16 05:36:32 -05:00

GiteaMirror closed this issue

2026-05-16 05:36:32 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#22868