starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 01:35:54 +03:00

[GH-ISSUE #1114] Deleting the admin_token in the webpanel deletes the whole admin_token key in the config.json file #787

New issue

Closed

opened 2026-03-03 02:03:12 +03:00 by kerem · 8 comments

kerem commented

2026-03-03 02:03:12 +03:00

Owner

Originally created by @szaimen on GitHub (Aug 25, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1114

Subject of the issue

Deleting the admin_token in the webpanel deletes the whole admin_token key in the config.json file

To reproduce:

open the admin panel and change a value and press on save
delete the admin token from admin panel and save again
see that the whole key was removed from the config.json file

Your environment

Bitwarden_rs version: 1.16.3

Install method: docker
Clients used:
Reverse proxy and version:
Version of mysql/postgresql:
Other relevant information:

Steps to reproduce

docker run -d --name bitwarden_rs \
  --user nobody \
  -e ADMIN_TOKEN="$ADMIN_PASS" \
  -e SIGNUPS_VERIFY=true \
  -e DOMAIN="https://$SUBDOMAIN" \
  -e SIGNUPS_ALLOWED=false \
  -p 1024:1024 \
  -e ROCKET_PORT=1024 \
  -e WEBSOCKET_ENABLED=true \
  -p 3012:3012 \
  -e LOG_FILE=/data/bitwarden.log \
  -e LOG_LEVEL=warn \
  -v /home/bitwarden_rs/:/data/ \
  -v /etc/timezone:/etc/timezone:ro \
  -v /etc/localtime:/etc/localtime:ro \
  --restart always \
  bitwardenrs/server:latest

Expected behaviour

Instead of deleting the whole key, it should just restore the default admin_token to the config.json file
(set the value of admin_token to the password-string that was set during the initial startup)

Actual behaviour

it just deletes the whole key, so that this key is missing from the json file.

Relevant logs

Originally created by @szaimen on GitHub (Aug 25, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1114 ### Subject of the issue  Deleting the admin_token in the webpanel deletes the whole admin_token key in the config.json file To reproduce: 1. open the admin panel and change a value and press on save 2. delete the admin token from admin panel and save again 3. see that the whole key was removed from the config.json file ### Your environment  * Bitwarden_rs version: 1.16.3  * Install method: docker * Clients used:  * Reverse proxy and version:  * Version of mysql/postgresql:  * Other relevant information: ### Steps to reproduce  ``` docker run -d --name bitwarden_rs \ --user nobody \ -e ADMIN_TOKEN="$ADMIN_PASS" \ -e SIGNUPS_VERIFY=true \ -e DOMAIN="https://$SUBDOMAIN" \ -e SIGNUPS_ALLOWED=false \ -p 1024:1024 \ -e ROCKET_PORT=1024 \ -e WEBSOCKET_ENABLED=true \ -p 3012:3012 \ -e LOG_FILE=/data/bitwarden.log \ -e LOG_LEVEL=warn \ -v /home/bitwarden_rs/:/data/ \ -v /etc/timezone:/etc/timezone:ro \ -v /etc/localtime:/etc/localtime:ro \ --restart always \ bitwardenrs/server:latest ``` ### Expected behaviour  Instead of deleting the whole key, it should just restore the default admin_token to the config.json file (set the value of admin_token to the password-string that was set during the initial startup) ### Actual behaviour  it just deletes the whole key, so that this key is missing from the json file. ### Relevant logs

kerem closed this issue

2026-03-03 02:03:13 +03:00

kerem commented

2026-03-03 02:03:13 +03:00

Author

Owner

@dani-garcia commented on GitHub (Aug 28, 2020):

What do you mean the default admin token? By default it's disabled, if you configure it with an environment variable, then deleting it from the admin page will use the value from the environment variable, but it won't save it to disk.

@dani-garcia commented on GitHub (Aug 28, 2020): What do you mean the default admin token? By default it's disabled, if you configure it with an environment variable, then deleting it from the admin page will use the value from the environment variable, but it won't save it to disk.

kerem commented

2026-03-03 02:03:13 +03:00

Author

Owner

@szaimen commented on GitHub (Aug 30, 2020):

What I mean is the following:

create an admin-token as environmental variable during the initial startup of the container
access the admin panel by using this admin-token
change the admin_token to something else
press save
now the config.json file is existing and the current admin_token is also written to the file
access the admin-panel again
delete the whole admin_token (to reset it to the default)
Save the config
now look into the config.json file and see that the whole admin_token entry is gone

I guess better whould be, if it was just changed back to the initial value and not just deleted

@szaimen commented on GitHub (Aug 30, 2020): What I mean is the following: 1. create an admin-token as environmental variable during the initial startup of the container 2. access the admin panel by using this admin-token 3. change the admin_token to something else 4. press save 5. now the config.json file is existing and the current admin_token is also written to the file 6. access the admin-panel again 7. delete the whole admin_token (to reset it to the default) 8. Save the config 9. now look into the config.json file and see that the whole admin_token entry is gone I guess better whould be, if it was just changed back to the initial value and not just deleted

kerem commented

2026-03-03 02:03:13 +03:00

Author

Owner

@szaimen commented on GitHub (Aug 30, 2020):

On the other hand: if the initial admin_token is stored inside the database, I guess it is completely okay, to do it this way.
So is the initial admin_token stored inside the database?
Edit: it doesn't seem to be the case.

@szaimen commented on GitHub (Aug 30, 2020): ~~On the other hand: if the initial admin_token is stored inside the database, I guess it is completely okay, to do it this way. So is the initial admin_token stored inside the database?~~ Edit: it doesn't seem to be the case.

kerem commented

2026-03-03 02:03:14 +03:00

Author

Owner

@BlackDex commented on GitHub (Oct 9, 2020):

@szaimen, but are you still able to login using the default admin key set as an env to login? Or are you not able to login at all anymore?

@BlackDex commented on GitHub (Oct 9, 2020): @szaimen, but are you still able to login using the _default_ admin key set as an env to login? Or are you not able to login at all anymore?

kerem commented

2026-03-03 02:03:14 +03:00

Author

Owner

@szaimen commented on GitHub (Oct 10, 2020):

but are you still able to login using the default admin key set as an env to login?

Yes, this works but it is bad for restore scenarios if you use docker (not docker-compose) and have lost the initial password.

@szaimen commented on GitHub (Oct 10, 2020): > but are you still able to login using the _default_ admin key set as an env to login? Yes, this works but it is bad for restore scenarios if you use docker (not docker-compose) and have lost the initial password.

kerem commented

2026-03-03 02:03:14 +03:00

Author

Owner

@BlackDex commented on GitHub (Oct 11, 2020):

If you use docker then you just lookup the env value in the configuration. Or you start a new docker with a different admin token.

Removing the token means no access at all. So even if we did disregard the env value, you can't login at all anymore. So that is probably as worse as reverting to the previous token.

@BlackDex commented on GitHub (Oct 11, 2020): If you use docker then you just lookup the env value in the configuration. Or you start a new docker with a different admin token. Removing the token means no access at all. So even if we did disregard the env value, you can't login at all anymore. So that is probably as worse as reverting to the previous token.

kerem commented

2026-03-03 02:03:14 +03:00

Author

Owner

@BlackDex commented on GitHub (Oct 11, 2020):

ps, if you really want to extract the current env values from a linux host, you could use

ps auxe | grep CONTAINER_NAME

@BlackDex commented on GitHub (Oct 11, 2020): ps, if you really want to extract the current env values from a linux host, you could use ```bash ps auxe | grep CONTAINER_NAME ```

kerem commented

2026-03-03 02:03:14 +03:00

Author

Owner

@szaimen commented on GitHub (Oct 11, 2020):

Hey, thanks for the advices! These don't fix the problem but I guess you are not willing to implement this. I will have to workaround this differently. So closing!

@szaimen commented on GitHub (Oct 11, 2020): Hey, thanks for the advices! These don't fix the problem but I guess you are not willing to implement this. I will have to workaround this differently. So closing!