search

clidey / whodb

A lightweight next-gen data explorer - Postgres, MySQL, SQLite, MongoDB, Redis, MariaDB & Elastic Search with Chat interface
https://whodb.clidey.com
GNU General Public License v3.0
1.96k stars 55 forks source link

[FR] Persist configs #98

Closed saschabrockel closed 3 months ago

saschabrockel commented 3 months ago

Hey there, first of all, great work! Really a nice tool and helpful to look into all my databases on my server without doing anything other than giving credentials.

One thing I'm worried about now is that if I close my browser or better said one day delete cookies etc. I lose all the databases I have set up. I saw that you allow to define configs in the environment variable. Still, I'm not sure how much I like it to have all of my database credentials in the environment variable of the container. The security aspect is critical.

So can we save it somewhere as a config file on the filesystem?

How do you save the configs in the browser? Is it a cookie or local storage?

hkdeman commented 3 months ago

Hey! Thank you for using WhoDB. Really glad to see you are liking it!

We currently store the credentials in cookies and the local storage of the browser so you would definitely lose your history if your browser storage is reset or you switch browsers.

With the environment variables config, we only share host, database type, database to the frontend. The password is not shared. The profile is then saved in the frontend, sent to the backend with the request, and then reloaded in the backend when necessary. This is to ensure that the sensitive credentials are not being forwarded to the frontend.

Would loading database profiles using docker-compose .env file help your use-case: https://docs.docker.com/compose/environment-variables/set-environment-variables/#use-the-env_file-attribute?

This would allow you to save the config in your computer and only load the environment variable in the container. We could potentially remove the environment variables from the container once the program has loaded them in the memory. Although, I am not sure how much more data safety would this bring.

saschabrockel commented 3 months ago

Ah okay, I didn't realize that the password wasn't part of the environment variables. The problem is that I don't use compose files for my unRAID server because they have templates and run the command as docker run command. Normally I also prefer compose files.

Yeah, it would not bring much more safety. I know this approach. It's never really safe. As well not when it is saved in a folder. It will always be saved somewhere as normal text.

hkdeman commented 3 months ago

Sorry I missed this reply!

The password is in the environment variables of the container (backend) but is not sent to the frontend.

Yeah protecting secrets is not easily possible like that. From my understanding, all docker environment variables are kept this way so I don't think it would be a big issue if your server is safe and under VPC or so.

Is there anything else we can do from our end to better support your use case?

saschabrockel commented 3 months ago

You answered. That is already enough :)

I close this issue now as it is no real issue and just was an idea. I will use the environment variables :)