mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-03-11 17:41:29 -05:00
/admin returns 422 on login #1261
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 @androidacy-user on GitHub (Apr 29, 2022).
Subject of the issue
Admin dashboard returns 422
Deployment environment
Install method: docker-compose
Clients used: browser
Reverse proxy and version: Nginx 1.21.0, behind cloudflare tunnel (previously known as argo tunnel) which is behind cloudflare itself
MySQL/MariaDB or PostgreSQL version: n/a
Other relevant details: IP_HEADER variable is set accordingly since we are running behind cloudflare
Steps to reproduce
Expected behaviour
Login and shows the dashboard
Actual behaviour
The 422 error is returned.
Troubleshooting data
complete `docker-compose logs`
@BlackDex commented on GitHub (Apr 29, 2022):
I can't see that paste , i need to login before i can see it it looks like.
Have you tried to see what happens if you take cloudflare out of the equation?
@androidacy-user commented on GitHub (Apr 29, 2022):
You can login with any account, it's just that
pastebinitmakes them privateAnd no, taking cloudflare out of the equation is not an option I will even consider. Seeing as our webserver isn't actually exposed to the internet whatsoever with our current setup, it'd require quite a bit of configuration reworking.
@BlackDex commented on GitHub (Apr 29, 2022):
That is not what i asked. I asked what happens if you bypass it. I guess that you as the admin would be able to do that.
The thing is, there is something send to Vaultwarden which is not understood. And the thing in between is cloudflare, and that could be an issue.
@androidacy-user commented on GitHub (Apr 29, 2022):
Let me rephrase again
We can't
Our setup would have to be almost ENTIRELY reworked to allow us to take cloudflare out of the equation. Even for an admin.
As it stands now, the firewall doesn't allow non cloudflare connections, nginx is only listening on localhost, and all web requests have to come through cloudflare tunnel.
This would also require us to issue a valid SSL certificate on the servers, as the only certificate installed is the cloudflare origin certificate which is only trusted by cloudflare, and require us to even temporarily expose our servers to the internet.
@BlackDex commented on GitHub (Apr 29, 2022):
Then we would need to see the actual http request coming in into Vaultwarden. Either via a tcpdump/wireshark or by enabling trace logging.
Also double check then nginx config compared with the examples in the wiki.
@androidacy-user commented on GitHub (Apr 29, 2022):
There is no magic bypass button in our case.
It would be really helpful if logs told us why the request isn't processable.
@androidacy-user commented on GitHub (Apr 29, 2022):
Is trace logging referring to setting
EXTENDED_LOGGING=true? Because that didn't seem to output anything extra related to the admin requests.@BlackDex commented on GitHub (Apr 29, 2022):
That is done by the webserver library (Rocket), which you can trigger to be a bit more verbose by setting logging to trace.
@BlackDex commented on GitHub (Apr 29, 2022):
LOG_LEVEL=trace@BlackDex commented on GitHub (Apr 29, 2022):
You could use an ssh tunnel maybe or ssh socks proxy to connect to it. There probably is a way to connect to it without even nginx in front of it.
@androidacy-user commented on GitHub (Apr 29, 2022):
http://sprunge.us/bWFEcv
The only one on the pastebinit list that works and isn't private by default
@androidacy-user commented on GitHub (Apr 29, 2022):
Ssh also goes through cloudflare, through their zero trust solution.
Nonetheless logs with the logging level set to trace are above, albeit with a few extra ASCII color codes in the mix.
@BlackDex commented on GitHub (Apr 29, 2022):
Please check your nginx config. It looks like it is sending a header to do an upgrade which isn't right.
Also, try if you can filter the cf-* headers in nginx so that they do not pas on to Vaultwarden.
@BlackDex commented on GitHub (Apr 29, 2022):
Then it still is ssh. Not sure if it then supports socks5 proxy or port tunneling. But if that is the case you could use that to bypass cloudflare.
@androidacy-user commented on GitHub (Apr 29, 2022):
The only Upgrade headers i see (CTRL-F'ing the log) are browser headers. NGINX only attempts the connection over http1.1 and http, and up until it hits cloudflare http2/3 doesn't even come into play.
@BlackDex commented on GitHub (Apr 29, 2022):
http1.1 supports upgrade.
But again, please try to filter the cloudflare headers and double check the nginx config with the examples in the wiki.
@androidacy-user commented on GitHub (Apr 29, 2022):
Okay, the only place upgrade headers are set is
/notifications/hubAnd the config is originally copy-pasted from the wiki. The only modifications are to work with cloudflare tunnel and cloudflare's origin cert, plus CSP, Access-Control-*, referrer-policy, and x-content-type-options.
@androidacy-user commented on GitHub (Apr 29, 2022):
Just for giggles, I recopied the config since it was a while ago when we initially set this up, only changing the listen, ssl, and adding one location directive for internal use, and still same result.
We're shooting in the dark here, because the logs even at higher levels, don't say what isn't processable. Just that something isn't.
@BlackDex commented on GitHub (Apr 29, 2022):
Well, a 422 is mostly because something is malformed. That could be headers, or the request body. For example, no correct new lines after headers or weird characters in the headers or body.
But, most of the time it is malformed body, so incorrect json for example. It could even be charset issues, or something which should be an integer and suddenly is a string, or the other way around. It could even be a simple thing as a difference between lower or uppercase characters if that is changed somewhere in between.
And that is why i asked to try and remove cloudflare from the equations to rule that out, since cloudflare is known to do some transformations sometimes with requests.
I can take a closer look in the morning if i can find anything more specific in the posted logs.
@BlackDex commented on GitHub (Apr 30, 2022):
@androidacybot , I'm looking at it right now.
But may i suggest that you change your admin password, since that is exposed now.
@BlackDex commented on GitHub (Apr 30, 2022):
Well, it looks like the client you are using, or CloudFlare is doing something to let your browser redirect using a
POSTinstead ofGETafter a possible correct login.I see the
POSTto login, i see that Vaultwarden responds with aLocationheader using 303 See Other as it's code, which should trigger the client to always useGET. But your client doesn't, it keeps thePOST.And that is what is causing the issues, since Vaultwarden expect that there is a
tokenprovided for aPOSTand causes the422error to happen.This is not something wrong on the Vaultwarden side, since Vaultwarden (and the Rocket library) is very strict in what they receive and verify the contents, if it doesn't matched what is programmed it will disallow the request.