Docker BitWarden - self hosted password manager using vaultwarden/server image

[Rusty]

You will not get a push notification it will just sync the changes. Are you saying that the changes are not passing at all? Like adding new items, new folder etc.

Again, no push notification will arrive. The github feature name is wrong imho

 

[maravac]

You will not get a push notification it will just sync the changes. Are you saying that the changes are not passing at all? Like adding new items, new folder etc.

Again, no push notification will arrive. The github feature name is wrong imho

yes, sure. I am talking about live syncing (not a push notification). I opened the same item in the Vautwarden web UI and my mobile app, added some notes to it in web UI, saved, but nothing changed in my mobile app

 

[Rusty]

yes, sure. I am talking about live syncing (not a push notification). I opened the same item in the Vautwarden web UI and my mobile app, added some notes to it in web UI, saved, but nothing changed in my mobile app

Check the log of the VW and see if its registering the new push feature as active

 

[maravac]

do you think it's OK? right now I just created a NEW FOLDER (which again is not synced into the mobile app, unless I refresh/sync it manually by pulling the screen down)
btw. what is the access_token? is it safe to post it here?

 

[paradeiser]

yes, I am running into the same troubles.

I did add the variables into my config.json (residing in Synology/docker/vaultwarden/)

"PUSH_ENABLED" : true,
"PUSH_INSTALLATION_ID" : "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
"PUSH_INSTALLATION_KEY" : "ABC…ABC",

I also removed my old "Evironment Variables" I once set directly in the container "Advanced Settings"

WEBSOCKET_PORT:        3012
WEBSOCKET_ENABLED:    true

When opening the web-vault, I get

Error: WebSocket failed to connect. The connection could not be found on the server, either the endpoint may not be a SignalR endpoint, the connection ID is not present on the server, or there is a proxy blocking WebSockets. If you have multiple servers check that sticky sessions are enabled.

in the Developer Console.

Also Push to my iOS App doesnt work.

I'm using Synologys built-in reverse proxy (Login-Portal) and also tried to add the "Custom Header" defaults for WebSocket for my "bitwarden.domain.com:443 > localhost:8280" rule :

Upgrade : $http_upgrade
Connection : $connection_upgrade

The container ports are unchanged (8280>80, 8212>3012)
But that didn't change anything.

What are we missing?
How may we debug?

Big thanks as always!
paradeiser

 

[ilbarone87]

@paradeiser and @maravac seem that you need to uninstall the client on your phone and install it back, and then it will start working.
For my client (iOS) after uninstalling the bw app client and then logging in, I got a prompt about enabling push notifications, after it started to work.

 

[Rusty]

@maravac & @paradeiser sorry for the late reply but I had a lot of work yesterday.

No changes are needed apart from what was already said, so I would follow up what @ilbarone87 said and give that a go.

 

[maravac]

I can confirm. Uninstalled/installed the mobile app. No prompt about enabling the push notification, but now the feature works.

 

[ilbarone87]

I can confirm. Uninstalled/installed the mobile app. No prompt about enabling the push notification, but now the feature works.

Yeah the prompt is only for iOS devices I believe.

 

[BobW]

I was having the same problem with my iOS devices and the suggestion from @ilbarone87 worked for me! Although the sync problem was only with the iPad (iPadOS version 16.4.1) and not on my iPhone (iOS version 14.4.2)....very strange!

 

[Telos]

Thanks @Rusty for the push update info. Works great without the 312 port.

A follow-up question. When I launched the update docker-compose.yml, I noticed warnings in the logs:

Should I simply remove those environmental variables from the compose file? If they are going to be overridden by the admin panel, I don't see their purpose.

 

[ilbarone87]

Thanks @Rusty for the push update info. Works great without the 312 port.

A follow-up question. When I launched the update docker-compose.yml, I noticed warnings in the logs:

Should I simply remove those environmental variables from the compose file? If they are going to be overridden by the admin panel, I don't see their purpose.

You can remove the signup safely, but keep admin_token that is to access the admin page.

 

[Rusty]

Thanks @Rusty for the push update info. Works great without the 312 port.

A follow-up question. When I launched the update docker-compose.yml, I noticed warnings in the logs:

Should I simply remove those environmental variables from the compose file? If they are going to be overridden by the admin panel, I don't see their purpose.

Well I still use both variables as I have not paid that much attention to the log. Also the admin token has been updated to the new “version” explained by the previous additions to this article. While this is the way vaultwarden does things I would leave it. In terms of signups, again, I haven’t checked if the settings is accessible via the admin page. If so, then I guess it can be removed as @ilbarone87 said.

 

[Telos]

I still use both variables as I have not paid that much attention to the log.

Using your write-up I added argon2 security (also changed my admin password in the process to get the new token). When I recreate the container, I cannot log into the admin panel, and the log still tells me

[NOTICE] You are using a plain text [ICODE]ADMIN_TOKEN which is insecure.[/ICODE]

So... the argon2 password fails, but the token is accepted as the "password" for the admin panel.

What am I missing?

UPDATE1: It's those danged single quote marks. Remove them! and all is good.

Not this:
ADMIN_TOKEN='$$argon2id$$v=19$$m=65540,t=2,p=4$$H5Xns1Juvmy4BR2rB0fRg4yn6O7CdIFRV4mw/J/y4iM$$pejf9RXHz2jYorvspelm5cnD/9Jf/BD6cnikiUASz0U'

But this:
ADMIN_TOKEN=$$argon2id$$v=19$$m=65540,t=2,p=4$$H5Xns1Juvmy4BR2rB0fRg4yn6O7CdIFRV4mw/J/y4iM$$pejf9RXHz2jYorvspelm5cnD/9Jf/BD6cnikiUASz0U

 

[Rusty]

Using your write-up I added argon2 security (also changed my admin password in the process to get the new token). When I recreate the container, I cannot log into the admin panel, and the log still tells me

[NOTICE] You are using a plain text [ICODE]ADMIN_TOKEN which is insecure.[/ICODE]

So... the argon2 password fails, but the token is accepted as the "password" for the admin panel.

What am I missing?

UPDATE1: It's those danged single quote marks. Remove them! and all is good.

Not this:
ADMIN_TOKEN='$$argon2id$$v=19$$m=65540,t=2,p=4$$H5Xns1Juvmy4BR2rB0fRg4yn6O7CdIFRV4mw/J/y4iM$$pejf9RXHz2jYorvspelm5cnD/9Jf/BD6cnikiUASz0U'

But this:
ADMIN_TOKEN=$$argon2id$$v=19$$m=65540,t=2,p=4$$H5Xns1Juvmy4BR2rB0fRg4yn6O7CdIFRV4mw/J/y4iM$$pejf9RXHz2jYorvspelm5cnD/9Jf/BD6cnikiUASz0U

Hmm not sure why my steps were with those, considering I use them as well, without them. Tnx for pointing it out. Altered.