It is learned from the official release page that since Vaultwarden version 1.29.0, WebSocket notification has been supported
(See details: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications ）
WebSocket notification is used to notify the browser, Bitwarden's desktop and browser extension client of some related events that have occurred. For example, entries in the password database have been modified or deleted. After receiving the notification, the client can take appropriate actions, such as refreshing modified entries, or removing deleted entries from its local cache. In this notification scheme, the Bitwarden client establishes a persistent WebSocket connection with the Bitwarden server (Vaultwarden in this example). Whenever the server has an event to report, it sends it to the client through this persistent connection.
WebSocket notifications are not applicable to mobile (Android/iOS) Bitwarden clients, These clients use native push notification services (FCM for Android, APNs for iOS). These must be configured separately using the push credentials of Bitwarden cloud service, which has been available since version 1.29.0.
(The above paragraph is machine translated. If you feel uncomfortable, please go to the original text for reading.).
That is, after this version, if ws is enabled, it will support real-time data synchronization, and each client's data will not need to rely on manual or scheduled synchronization to refresh data,
But only enabling ws is not enough. If the mobile terminal wants to use it, it must use The official push service provided by Bitwarden
In fact, as early as 21 years ago, shortly after the deployment, I wrote a special article recording the next installation steps, so this article will not repeat it, but simply describe the key steps
https://vv1234.cn/archives/606.html
One by one as mentioned above, first enable WebSocket
It's very simple. If you are an external service provider of Nginx
Added in the original reverse proxy configuration file
proxy_ set_ header Upgrade $http_ upgrade;
proxy_ set_ header Connection $connection_ upgrade;
Only when the reverse proxy service is forwarded to your backend with the Upgrade and Connection request headers, can the protocol upgrade or switch be completed
Example:
proxy_ pass http://127.0.0.1:8333 ; proxy_ http_ version 1.1; proxy_ set_ header Upgrade $http_ upgrade; proxy_ set_ header Connection $connection_ upgrade; proxy_ set_ header Host $host; proxy_ set_ header X-Real-IP $remote_ addr; proxy_ set_ header X-Forwarded-For $proxy_ add_ x_ forwarded_ for; proxy_ set_ header X-Forwarded-Proto $scheme; proxy_ connect_ timeout 777; proxy_ send_ timeout 777; proxy_ read_ timeout 777; send_ timeout 777;
If the mobile terminal pushes, it needs to arrive first https://bitwarden.com/host/?ref=vv1234.cn Apply to register the installation ID and key,
Only our private servers can be configured to use the official Push service
Enter your email, Gmail is recommended to avoid failing to receive emails, and then select the data storage location (if different data centers are selected in the US/EU, the Push URI needs to be adjusted accordingly, such as https://push.bitwarden.com or https://push.bitwarden.eu )
After submission, the page will display the information of Installation ID and Installation KEY, which must be kept properly
Then, when using Docker to deploy and install, we can add it to the environment variables configured as follows:
- PUSH_ ENABLED=true - PUSH_ INSTALLATION_ ID= - PUSH_ INSTALLATION_ KEY= - PUSH_ RELAY_ BASE_ URI= https://push.bitwarden.com
If the mobile terminal cannot synchronize normally, you can try to reinstall the application and log in to your private server again so that the push notification service can register and run normally.
Well, that's about it. I'm finished. I'm too lazy to use my private server~
