mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
login with new bitwarden desktop client #1860
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @extremMiSt on GitHub (Feb 21, 2024).
Subject of the issue
when trying to log into a vaultwarden instance using the latest (2024.2.0) bitwarden desktop client.
it does a lot of weird stuff and then goes back to the login screen.
login works with the firefox addon, webclient, andoird client, and and older version of the desktop client (I tried 2024.1.0 appimage, only works once, cause it auto updates).
vaultwarden version: Version 1.30.3 (pulled the fresh docker image today before reporting)
Install method: docker
Clients used:
see above, problem only occurs with desktop client.
Reverse proxy and version: nginx
Other relevant details:
I am on linux mint with the client.
Steps to reproduce
try to login with username+password
Expected behaviour
I get logged in and can use the passwordmanager
Actual behaviour
see attached video. it shows what happens after I tried to log in.
(email is censored, cause cause).
https://github.com/dani-garcia/vaultwarden/assets/1934286/f6adf5aa-057f-4c5c-8d4c-bbcb87aefa6a
Troubleshooting data
On the server during this failed login attempt I get the following output:
[2024-02-21 18:59:49.356][request][INFO] GET /api/config
[2024-02-21 18:59:49.356][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 18:59:49.356][request][INFO] GET /api/devices/knowndevice
[2024-02-21 18:59:49.359][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK
[2024-02-21 18:59:51.188][request][INFO] GET /api/devices/knowndevice
[2024-02-21 18:59:51.189][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK
[2024-02-21 18:59:55.192][request][INFO] POST /identity/accounts/prelogin
[2024-02-21 18:59:55.194][response][INFO] (prelogin) POST /identity/accounts/prelogin => 200 OK
[2024-02-21 18:59:56.096][request][INFO] POST /identity/connect/token
[2024-02-21 18:59:56.784][vaultwarden::api::identity][INFO] User [redacted] logged in successfully. IP: 172.17.0.1
[2024-02-21 18:59:56.785][response][INFO] (login) POST /identity/connect/token => 200 OK
[2024-02-21 18:59:56.966][request][INFO] GET /api/config
[2024-02-21 18:59:56.967][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 18:59:57.173][request][INFO] GET /notifications/hub?access_token=[redacted]
[2024-02-21 18:59:57.174][vaultwarden::api::notifications][INFO] Accepting Rocket WS connection from 172.17.0.1
[2024-02-21 18:59:57.174][response][INFO] (websockets_hub) GET /notifications/hub?<data..> => 200 OK
[2024-02-21 18:59:57.175][request][INFO] POST /identity/connect/token
[2024-02-21 18:59:57.181][response][INFO] (login) POST /identity/connect/token => 200 OK
[2024-02-21 18:59:57.223][request][INFO] GET /api/sync?excludeDomains=true
[2024-02-21 18:59:57.223][auth][ERROR] Unauthorized Error: No access token provided
[2024-02-21 18:59:57.224][vaultwarden::api::core::ciphers::_][WARN] Request guard `Headers` failed: "No access token provided".
[2024-02-21 18:59:57.224][response][INFO] (sync) GET /api/sync?<data..> => 401 Unauthorized
[2024-02-21 18:59:57.446][vaultwarden::api::notifications][INFO] Closing WS connection from 172.17.0.1
[2024-02-21 18:59:57.469][request][INFO] GET /api/config
[2024-02-21 18:59:57.470][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 18:59:58.201][request][INFO] GET /api/config
[2024-02-21 18:59:58.201][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 18:59:58.202][request][INFO] GET /api/devices/knowndevice
[2024-02-21 18:59:58.203][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK
@extremMiSt commented on GitHub (Feb 21, 2024):
aaand never mind ...
configuration snafu on my part.
somehow I had http in the custom server field in the client.
still interesting how it somehow worked with the older client, cause it definitely should not have.
@Gerardv514 commented on GitHub (Feb 23, 2024):
Well maybe something like this should stay open. A few questions, Should http even be allowed? If not then we should error with the reason. If http is allowed why does it go bazerk like that.