mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-08-27 05:35:03 -05:00
WEB_VAULT_ENABLED=false & 404: Not Found #3685
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vaultwarden#3685
Reference in New Issue
Block a user
Originally created by @mannp on GitHub (Jul 15, 2018).
Thanks for your work in creatimg this :)
I have set the .env variable WEB_VAULT_ENABLED=false, which appears to work great and disable the web vault login page.
That said, I get the following error and wondered if I could get it to display a legal landing page, index.html instead of this 404 not found?
Is it also possible to remove ' Rocket ' from this message so the system behind the page is not given to others.
Thanks in advance
and ..
@mprasil commented on GitHub (Jul 15, 2018):
I think the best thing to do is to leave Vault enabled and then replace the Vault directory with your own, that will only have your index.html.
@mannp commented on GitHub (Jul 15, 2018):
I want to use the vault alot of the time to edit and import items and then disable it after those edits and imports are done.
So copying new files in to the vault directory doesn't feel practical.
The .env variable is there and seems to work, but doesn't display a html page, which seems odd and the issue I am highlighting.
Isn't that a bug rather than a question, or is it supposed to show a 404?
@mprasil commented on GitHub (Jul 15, 2018):
There's nothing to show when the Vault is disabled, so throwing 404 is IMHO correct. Perhaps we could respond with bad request instead?
As for your use case, perhaps you can have two directories and switch between them using
WEB_VAULT_FOLDER?But I think you should just have privately accessible Vault somewhere (it's just bunch of static files) and have the Vault disabled / overriden permanently.
@mprasil commented on GitHub (Jul 15, 2018):
BTW, what's the reason to disable Vault? If it's security, there's basically no benefit from disabling it. Vault is basically just a bunch of static files. The Vault interface itself is then calling the same API as any other client. So all you achieve is disable static file serving.
@mannp commented on GitHub (Jul 15, 2018):
If the vault is disabled its throwing a 404 which is an error code and doesn't seem right.
If the env variable redirected from the vault directory to another directory /vault_disabled then we could place a basic index.html in that directory to be picked up when the env variable WEB_VAULT_ENABLED=false
I guess there was a reason why the env variable was added as its there and works, but it seems it just needs redirecting to one static html file, rather than thowing a 404.
@mprasil commented on GitHub (Jul 15, 2018):
So I don't think returning 404 is necessary a bad thing. 404 is an error code, error codes exist for an reason. I find returning 404 ("not found") for nonexistent resource request quite OK.
WEB_VAULT_ENABLED=falsedisables static file hosting, that's essentially all it does. If you wanted to serve some static file, it would defy the entire purpose of that setting and you can do just that by placing the index.html file to wherever yourWEB_VAULT_FOLDERis set.However I'm marking this as bug as I've noticed that we report either
500or404for nonexistent paths depending howWEB_VAULT_ENABLEDis set. We should be consistent here.@mannp commented on GitHub (Jul 17, 2018):
Ok thanks, i see your point of view but see 404 as poor configuration compared to 401 Unauthorised or 403 Forbidden being more specific :)
@mprasil commented on GitHub (Jul 17, 2018):
I think I don't quite follow your logic there. Client is asking for a resource (/index.html for example) that doesn't exist on the server as far as server is concerned. It tried to find a route to serve the request, but failed to find it.
In my mind 404 "Not found" is completely reasonable response that explains the failure clearly. 401 would imply that this is just access right issue, which is not true.
403 might be a reasonable response, but the problem is that this kinda implies that there is something to serve if it wasn't forbidden, but we don't really know that. There might be some files, there might not. Server doesn't know. It's literary just serving static files and we don't really know whether they are there until someone requests specific file and such serving isn't disabled. Once we receive said request, we try to find the file (if enabled) then try to find API call that could handle the request and eventually we fail when nothing is found.
@mprasil commented on GitHub (Jul 17, 2018):
Maybe you actually want some meaningful response code only for the
/path? With that one we actually kinda know that it should be served by index.html file if not disabled.@mannp commented on GitHub (Jul 17, 2018):
I am not looking at the technical response of the code and whether that is correct for what the code is trying to do.
I am referring to the end result.
So I wouldn't expect the end result for a disabled webserver to be 'not found' and btw I am a rocket server too, but instead a more mute response of 'nothing to see here...'
@mprasil commented on GitHub (Jul 18, 2018):
The thing is, that when you disable the Vault, it is still serving the API. I've just checked the original API implementation and they return 404 for any path that isn't available. So I'd say we should mirror the behavior for maximum compatibility.
If you want some user friendly front page for users you can provide your own static page and point
WEB_VAULT_FOLDERto the directory.@mannp commented on GitHub (Jul 18, 2018):
I get the message it won't change, but comparing the original api which has no concept of disabling the vault is misleading.
The variable should be web_server_enabled as it is not disabling the vault directly.
I don't want to create a static page, so that's not an option, I'd rather just have the variable do a job rather than what appears to be a hack.
I get you feel its not worth your effort to change.
@mprasil commented on GitHub (Jul 18, 2018):
It's not about my time. Here's how I think about it: the web Vault is just nice to have feature, that serves static files for Vault if it's enabled. When it's disabled, the service should behave just like a standalone API server. Official API server returns 404 for any path that doesn't exist in the API and so should we.
To explain this in technical terms, what we're doing is we try to serve the request as an API call and only when that fails, we try to match the request with some file from the
WEB_VAULT_FOLDER. If we fail that or if theWEB_VAULT_ENABLEDis set tofalsewe return404just like the original API.Now the only case I can see us handling differently is the
/path which is handled in a special way. So maybe we could extend it and return403for that? Would that work for you?@mannp commented on GitHub (Jul 18, 2018):
The special case you mention is relating to the consistency point you raised earlier and not my original point.
I understand your technical points but feel they are mixing issues as the original api does not have a concept of no vault, so stating you are keeping compatible with the api, when it has no concept of no vault, seems odd.
I will close this from my perspective, thanks for taking the time to explain.
@mprasil commented on GitHub (Jul 18, 2018):
Original API has no concept of integrated Vault. It's a separate service completely. When you disable vault here, I'd like it to behave just like that API, hope that makes sense.
Thanks for reporting this anyways, we've found and fixed one bug thanks to that, so it definitely wasn't in vain.