Admin API rejects invalid tokens with 303 instead of 401 status code #1353

New Issue

GiteaMirror · 2025-11-07T07:04:24-06:00

GiteaMirror commented

2025-11-07 07:04:24 -06:00

Originally created by @linkvt on GitHub (Aug 27, 2022).

Hi,

first of all thanks for this nice project, I really appreciate it!

Subject of the issue

I was setting up fail2ban for my Vaultwarden instance and noticed, that on invalid tokens the Vaultwarden Admin API responds with a 303 HTTP status code instead of a 401 I usually see.

Deployment environment

I removed most of the fields as they are IMO irrelevant.

vaultwarden version: 1.25.2

Steps to reproduce

Try to log into the admin UI with an incorrect token.

Expected behaviour

HTTP response with 401 Unauthorized status code.

Actual behaviour

HTTP response with 303 See Other redirect status code.

Comment

Is this really intended from a behaviour perspective, see the implementation at
60ed5ff99d/src/api/admin.rs (L181)

If I understand the comment https://github.com/dani-garcia/vaultwarden/discussions/2448#discussioncomment-2666185 correctly it might be intended by you as the authors/contributors, but this is as far as I know not the correct behaviour for bad requests due to user issues (-> 4xx status code) due to failing authentication (narrowing to 401 Unauthorized).

While I understand the reasoning that a GET should follow the POST in this case, it does not make sense to me that a 303 is used.

Thanks for looking into this already!

Best, Vincent

P.S.: If you agree that this can be changed to a 401 I would be happy to open the PR myself.

Originally created by @linkvt on GitHub (Aug 27, 2022).   Hi, first of all thanks for this nice project, I really appreciate it! ### Subject of the issue I was setting up fail2ban for my Vaultwarden instance and noticed, that on invalid tokens the Vaultwarden Admin API responds with a 303 HTTP status code instead of a 401 I usually see.  ### Deployment environment I removed most of the fields as they are IMO irrelevant.     * vaultwarden version: 1.25.2  ### Steps to reproduce  Try to log into the admin UI with an incorrect token. ### Expected behaviour HTTP response with [401 Unauthorized](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401) status code.  ### Actual behaviour HTTP response with 303 See Other redirect status code.  ### Comment Is this really intended from a behaviour perspective, see the implementation at https://github.com/dani-garcia/vaultwarden/blob/60ed5ff99d15dec0b82c85987f9a3e244b8bde91/src/api/admin.rs#L181 If I understand the comment https://github.com/dani-garcia/vaultwarden/discussions/2448#discussioncomment-2666185 correctly it might be intended by you as the authors/contributors, but this is as far as I know not the correct behaviour for bad requests due to user issues (-> 4xx status code) due to failing authentication (narrowing to 401 Unauthorized). While I understand the reasoning that a GET should follow the POST in this case, it does not make sense to me that a 303 is used. Thanks for looking into this already! Best, Vincent P.S.: If you agree that this can be changed to a 401 I would be happy to open the PR myself.

GiteaMirror added the enhancement low priority labels 2025-11-07 07:04:24 -06:00

GiteaMirror closed this issue

2025-11-07 07:04:24 -06:00

GiteaMirror commented

2025-11-07 07:04:25 -06:00

@BlackDex commented on GitHub (Aug 27, 2022):

I would need to check this. While a 401 would normally be a valid answer to an invalid login. There should be anything wrong with this 303 either. There are other sites which just redirect you to a different page when failed to login instead of providing a 401.

What is the main reason for not keeping this a 303?

@BlackDex commented on GitHub (Aug 27, 2022): I would need to check this. While a 401 would normally be a valid answer to an invalid login. There should be anything wrong with this 303 either. There are other sites which just redirect you to a different page when failed to login instead of providing a 401. What is the main reason for not keeping this a 303?

GiteaMirror commented

2025-11-07 07:04:25 -06:00

@linkvt commented on GitHub (Aug 27, 2022):

Thanks for the quick reply!

My main reason is that I cannot distinguish successful from invalid logins while looking e.g. at access logs as both appear like "POST /admin HTTP/2.0" 303

As I also have never ever seen a site returning the 303 status code until today (while not being a junior wrt web dev) I googled and checked what others said and tbh I don't think that 303 is used correctly in more than this place.
When doing a logout I also see a 303 even when the logout is already a GET request - according to the HTTP Spec this behaviour is to my understanding not correct.

Examples results that indicate the 303 being used incorrectly are

From my limited understanding of the Vaultwarden Admin page it seems as if the API does too much and should pass some logic to the frontend. A REST API would return 401 after which the web app would understand that the user is authorized and show im e.g. the login page at /admin/login .
After a successful login the backend doesn't tell the frontend where to go, the web app knows that the user is authorized now and redirects him to the admin dashboard.

I know that there are many ways on how to solve this, but this is the behaviour I usually find in single page applications which is why I would keep it conformant and not use the 303.

@linkvt commented on GitHub (Aug 27, 2022): Thanks for the quick reply! My main reason is that I cannot distinguish successful from invalid logins while looking e.g. at access logs as both appear like `"POST /admin HTTP/2.0" 303` As I also have never ever seen a site returning the 303 status code until today (while not being a junior wrt web dev) I googled and checked what others said and tbh I don't think that 303 is used correctly in more than this place. When doing a logout I also see a 303 even when the logout is already a GET request - according to the HTTP Spec this behaviour is to my understanding not correct. Examples results that indicate the 303 being used incorrectly are - https://stackoverflow.com/questions/2839585/what-is-correct-http-status-code-when-redirecting-to-a-login-page - https://blog.airbrake.io/blog/http-errors/303-see-other - https://stackoverflow.com/questions/36220029/http-status-to-return-after-trying-to-logout-without-being-logged-in - https://httpwg.org/specs/rfc7231.html#status.303 From my limited understanding of the Vaultwarden Admin page it seems as if the API does _too much_ and should pass some logic to the frontend. A REST API would return 401 after which the web app would understand that the user is authorized and show im e.g. the login page at `/admin/login` . After a successful login the backend doesn't tell the frontend where to go, the web app knows that the user is authorized now and redirects him to the admin dashboard. I know that there are many ways on how to solve this, but this is the behaviour I usually find in single page applications which is why I would keep it conformant and not use the 303.

GiteaMirror commented

2025-11-07 07:04:25 -06:00

@BlackDex commented on GitHub (Aug 27, 2022):

I'm not for or against any changes. I think this is a redirect because that is how the flash messages from Rocket are setup.
It can be solved an other way, like using a template which will show an error message and return a 401 or whatever.

So, it's more a historical thing i guess.

@BlackDex commented on GitHub (Aug 27, 2022): I'm not for or against any changes. I think this is a redirect because that is how the flash messages from Rocket are setup. It can be solved an other way, like using a template which will show an error message and return a 401 or whatever. So, it's more a historical thing i guess.

GiteaMirror commented

2025-11-07 07:04:25 -06:00

@linkvt commented on GitHub (Aug 27, 2022):

Ah ok I understand, what do you think about only changing the 303 of an invalid login to a 401?
This way nothing would change for successful logins and failed logins would be handled correctly as failed logins don't need a redirect (as we are already on the correct page) so this should not break anything eiter?

@linkvt commented on GitHub (Aug 27, 2022): Ah ok I understand, what do you think about only changing the 303 of an invalid login to a 401? This way nothing would change for successful logins and failed logins would be handled correctly as failed logins don't need a redirect (as we are already on the correct page) so this should not break anything eiter?

GiteaMirror commented

2025-11-07 07:04:25 -06:00

@BlackDex commented on GitHub (Aug 27, 2022):

If I'm correct, the flash messages only supports redirects. So there need to be some more changes then just adding 401 somewhere.

@BlackDex commented on GitHub (Aug 27, 2022): If I'm correct, the flash messages only supports redirects. So there need to be some more changes then just adding 401 somewhere.

GiteaMirror commented

2025-11-07 07:04:26 -06:00

@BlackDex commented on GitHub (Sep 6, 2022):

@linkvt I have created a PR which should fix this. See #2729.

@BlackDex commented on GitHub (Sep 6, 2022): @linkvt I have created a PR which should fix this. See #2729.

GiteaMirror commented

2025-11-07 07:04:26 -06:00

@linkvt commented on GitHub (Sep 8, 2022):

@BlackDex thanks a lot for solving this issue, can't wait to test it 😃

@linkvt commented on GitHub (Sep 8, 2022): @BlackDex thanks a lot for solving this issue, can't wait to test it 😃

GiteaMirror referenced this issue

2025-11-07 07:55:25 -06:00