/admin returns 422 on login #1261

Closed
opened 2025-11-07 07:01:52 -06:00 by GiteaMirror · 21 comments
Owner

Originally created by @androidacy-user on GitHub (Apr 29, 2022).

Subject of the issue

Admin dashboard returns 422

Deployment environment

  • vaultwarden version: 1.24.0
  • 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

  1. Go to /admin
  2. Input correct password
  3. See:
422: Unprocessable Entity
The request was well-formed but was unable to be followed due to semantic errors.

Rocket

Expected behaviour

Login and shows the dashboard

Actual behaviour

The 422 error is returned.

Troubleshooting data

complete `docker-compose logs`
Attaching to bitwardenrs
bitwardenrs    | /--------------------------------------------------------------------\
bitwardenrs    | |                        Starting Vaultwarden                        |
bitwardenrs    | |                           Version 1.24.0                           |
bitwardenrs    | |--------------------------------------------------------------------|
bitwardenrs    | | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
bitwardenrs    | | official channels to report bugs/features, regardless of client.   |
bitwardenrs    | | Send usage/configuration questions or feature requests to:         |
bitwardenrs    | |   https://vaultwarden.discourse.group/                             |
bitwardenrs    | | Report suspected bugs/issues in the software itself at:            |
bitwardenrs    | |   https://github.com/dani-garcia/vaultwarden/issues/new            |
bitwardenrs    | \--------------------------------------------------------------------/
bitwardenrs    | 
bitwardenrs    | [INFO] No .env file found.
bitwardenrs    | 
bitwardenrs    | [WARNING] The following environment variables are being overriden by the config file,
bitwardenrs    | [WARNING] please use the admin panel to make changes to them:
bitwardenrs    | [WARNING] SIGNUPS_ALLOWED, ADMIN_TOKEN, IP_HEADER, SMTP_HOST, SMTP_SSL, SMTP_PORT, SMTP_FROM, SMTP_USERNAME, SMTP_PASSWORD
bitwardenrs    | 
bitwardenrs    | Listening for new connections on 0.0.0.0:3012.
bitwardenrs    | Rocket has launched from http://0.0.0.0:80
bitwardenrs    | Accepted a new tcp connection from 172.18.0.1:39474.
bitwardenrs    | Accepted a new tcp connection from 172.18.0.1:39476.
bitwardenrs    | GET /api/accounts/revision-date
bitwardenrs    | GET /api/accounts/revision-date (revision_date) => 200 OK
bitwardenrs    | GET /admin
bitwardenrs    | GET /admin [2] (admin_login) => 200 OK
bitwardenrs    | POST /admin
bitwardenrs    | POST /admin (post_admin_login) => 303 See Other
bitwardenrs    | POST /admin
bitwardenrs    | POST /admin (post_admin_login) => 422 Unprocessable Entity
bitwardenrs    | Accepted a new tcp connection from 172.18.0.1:39480.
bitwardenrs    | Accepted a new tcp connection from 172.18.0.1:39482.
bitwardenrs    | GET /api/accounts/revision-date
bitwardenrs    | GET /api/accounts/revision-date (revision_date) => 200 OK
Originally created by @androidacy-user on GitHub (Apr 29, 2022). <!-- # ### NOTE: Please update to the latest version of vaultwarden before reporting an issue! This saves you and us a lot of time and troubleshooting. See: * https://github.com/dani-garcia/vaultwarden/issues/1180 * https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/redact personal or confidential information, such as passwords, IP addresses, and DNS names as appropriate. --> ### Subject of the issue Admin dashboard returns 422 ### Deployment environment <!-- ========================================================================================= Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab. That will auto-generate most of the info requested in this section. ========================================================================================= --> <!-- The version number, obtained from the logs (at startup) or the admin diagnostics page --> <!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden --> <!-- Remember to check if your issue exists on the latest version first! --> * vaultwarden version: 1.24.0 <!-- How the server was installed: Docker image, OS package, built from source, etc. --> * Install method: docker-compose * Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) --> browser * Reverse proxy and version: <!-- if applicable --> Nginx 1.21.0, behind cloudflare tunnel (previously known as argo tunnel) which is behind cloudflare itself * MySQL/MariaDB or PostgreSQL version: <!-- if applicable --> n/a * Other relevant details: IP_HEADER variable is set accordingly since we are running behind cloudflare ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> 1. Go to /admin 2. Input correct password 3. See: ``` 422: Unprocessable Entity The request was well-formed but was unable to be followed due to semantic errors. Rocket ``` ### Expected behaviour <!-- Tell us what you expected to happen --> Login and shows the dashboard ### Actual behaviour <!-- Tell us what actually happened --> The 422 error is returned. ### Troubleshooting data <!-- Share any log files, screenshots, or other relevant troubleshooting data --> <details> <summary>complete `docker-compose logs`</summary> ``` Attaching to bitwardenrs bitwardenrs | /--------------------------------------------------------------------\ bitwardenrs | | Starting Vaultwarden | bitwardenrs | | Version 1.24.0 | bitwardenrs | |--------------------------------------------------------------------| bitwardenrs | | This is an *unofficial* Bitwarden implementation, DO NOT use the | bitwardenrs | | official channels to report bugs/features, regardless of client. | bitwardenrs | | Send usage/configuration questions or feature requests to: | bitwardenrs | | https://vaultwarden.discourse.group/ | bitwardenrs | | Report suspected bugs/issues in the software itself at: | bitwardenrs | | https://github.com/dani-garcia/vaultwarden/issues/new | bitwardenrs | \--------------------------------------------------------------------/ bitwardenrs | bitwardenrs | [INFO] No .env file found. bitwardenrs | bitwardenrs | [WARNING] The following environment variables are being overriden by the config file, bitwardenrs | [WARNING] please use the admin panel to make changes to them: bitwardenrs | [WARNING] SIGNUPS_ALLOWED, ADMIN_TOKEN, IP_HEADER, SMTP_HOST, SMTP_SSL, SMTP_PORT, SMTP_FROM, SMTP_USERNAME, SMTP_PASSWORD bitwardenrs | bitwardenrs | Listening for new connections on 0.0.0.0:3012. bitwardenrs | Rocket has launched from http://0.0.0.0:80 bitwardenrs | Accepted a new tcp connection from 172.18.0.1:39474. bitwardenrs | Accepted a new tcp connection from 172.18.0.1:39476. bitwardenrs | GET /api/accounts/revision-date bitwardenrs | GET /api/accounts/revision-date (revision_date) => 200 OK bitwardenrs | GET /admin bitwardenrs | GET /admin [2] (admin_login) => 200 OK bitwardenrs | POST /admin bitwardenrs | POST /admin (post_admin_login) => 303 See Other bitwardenrs | POST /admin bitwardenrs | POST /admin (post_admin_login) => 422 Unprocessable Entity bitwardenrs | Accepted a new tcp connection from 172.18.0.1:39480. bitwardenrs | Accepted a new tcp connection from 172.18.0.1:39482. bitwardenrs | GET /api/accounts/revision-date bitwardenrs | GET /api/accounts/revision-date (revision_date) => 200 OK ``` </summary>
Author
Owner

@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?

@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?
Author
Owner

@androidacy-user 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?

You can login with any account, it's just that pastebinit makes them private

And 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.

@androidacy-user 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? You can login with any account, it's just that `pastebinit` makes them private And 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.
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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): There is no magic bypass button in our case. It would be really helpful if logs told us _why_ the request isn't processable.
Author
Owner

@androidacy-user 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.

Is trace logging referring to setting EXTENDED_LOGGING=true? Because that didn't seem to output anything extra related to the admin requests.

@androidacy-user 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. Is trace logging referring to setting `EXTENDED_LOGGING=true`? Because that didn't seem to output anything extra related to the admin requests.
Author
Owner

@BlackDex 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.

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): > There is no magic bypass button in our case. > > It would be really helpful if logs told us _why_ the request isn't processable. That is done by the webserver library (Rocket), which you can trigger to be a bit more verbose by setting logging to trace.
Author
Owner

@BlackDex commented on GitHub (Apr 29, 2022):

LOG_LEVEL=trace

@BlackDex commented on GitHub (Apr 29, 2022): `LOG_LEVEL=trace`
Author
Owner

@BlackDex 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.

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.

@BlackDex 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. 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.
Author
Owner

@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): http://sprunge.us/bWFEcv The only one on the pastebinit list that works and isn't private by default
Author
Owner

@androidacy-user 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.

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.

@androidacy-user 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. 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.
Author
Owner

@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): 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.
Author
Owner

@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.

@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.
Author
Owner

@androidacy-user 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.

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.

@androidacy-user 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. 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.
Author
Owner

@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.

@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.
Author
Owner

@androidacy-user commented on GitHub (Apr 29, 2022):

Okay, the only place upgrade headers are set is /notifications/hub

And 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): Okay, the only place upgrade headers are set is `/notifications/hub ` And 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.
Author
Owner

@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.

@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.
Author
Owner

@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 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.
Author
Owner

@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): @androidacybot , I'm looking at it right now. But may i suggest that you change your admin password, since that is exposed now.
Author
Owner

@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 POST instead of GET after a possible correct login.

I see the POST to login, i see that Vaultwarden responds with a Location header using 303 See Other as it's code, which should trigger the client to always use GET. But your client doesn't, it keeps the POST.

And that is what is causing the issues, since Vaultwarden expect that there is a token provided for a POST and causes the 422 error 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.

@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 `POST` instead of `GET` after a possible correct login. I see the `POST` to login, i see that Vaultwarden responds with a `Location` header using [303 See Other](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303) as it's code, which should trigger the client to always use `GET`. But your client doesn't, it keeps the `POST`. And that is what is causing the issues, since Vaultwarden expect that there is a `token` provided for a `POST` and causes the `422` error 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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#1261