I have vaultwarden on my Synology NAS, everything looks like okay, I can log in in browser, but i cannot login via 3rd party bitwarden browser addon.
At the bitwarden addon I changed the server URL to my NAS address (Ofc its https) but when i enter my email+pass it showns incorrect email and password.
Another interest thing: In my other browser (i previously logged in) the master password works well. The email address is ok. Can someone confirm this issue?
The android client shows: failed to connect (to the server’s ip or domain address)
I just registered on this discourse because i’m having the exact same problem all of a sudden.
(and… it seems I have it working again, too… in a superweird way)
Have vaultwarden/server:latest running after reading the NOTE on github/here about running the latest version. Login-page lists: 2022.10.0
The issue is that web-logins work fine, but App/Plugin logins do not.
The plugin reports username/pass is wrong.
The docker-container log lists: [vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP:… etc.
but, also, the next line is interesting:
[response][INFO] (login) POST /identity/connect/token => 400 Bad Request
(i’ll explain why it is interesting in a bit)
I just registered, and Discourse is telling me i can only include two URL’s as a new user… so my URL’s are somewhat weirdly formatted for that reason.
I have docker running on Synology DSM with the latest Vaultwarden container.
It has port 3012–>3012 and 5151–>80 mappings
In DSM I have LetsEncrypt certificates and ReverseProxy exposing the whole thing on warden. exampledomain. com
This whole setup has run very well for a long while now and only just started producing issues for me yesterday.
My first steps were to edit /etc/hosts to point the warden .exampledomain. com name directly to the INTERNAL IP so that there’s (less) DSM stuff in the way. This leads to the same behaviour: Web works but Plugins and app do not.
But, going one step further, I changed the login-url from https:/ /warden.exampledomain.com to HTTP:/
/warden.exampledomain.com :5151 to prevent there being any reverse-proxy handling in between at all.
Lo and behold, suddenly I can login!
But, here’s where it gets weird. If I revert my server-settings to use https:/ /warden.exampledomain.com AND edit my /etc/hosts file again to use the external IP for it once more, it STILL works.
Even more interesting is that it suddenly works (again) for all OTHER devices that had been having issues logging in via their browser-plugins.
So, to do a TLDR;
None of my desktop/laptops can login with master-password on bitwarden-plugins in CHrome/Firefox
Weblogin always works, from any device
Configured /etc/hosts and Bitwarden-plugin server-setting on desktop to connect DIRECTLY to vaultwarden-port
Logged in succesfully with bitwarden-plugin on desktop
Reverted /etc/hosts and Bitwarden-plugin server-setting to use external IP, https on Desktop
Login STILL works
Testing on other devices show that they now (all?) seem to work too; without any further changes involved.
Can this be some kind of token that should get set (but never does) ?
Is it something the reverse-proxy of DSM is stripping from the conversation in some way , setting a token that has some kind of expiry-time …that my install hit 1 day ago, and will hit me again in $x days ?
It does not seem device-related so much as it seems Vaultwarden-rs related, wrt. the particular way it is or should be installed when running it on a Docker-container on DSM (it seems).
Many Thanks! I had the same issue because I’ve got a docker-compose file with the old bitwarden server image (bitwardenrs) but took a time to figure out the newer image has actually another name so i upgraded it to the latest version and worked, thank you.
Hello @BlackDex I’ve run into this issue just now, at the very least I cannot login under Firefox using the official extension and a server I deployed just today.