SECRET_KEY should be randomly set about container-healthchecks HOT 13 CLOSED

When the SECRET_KEY is changed you may lose data in the database, that is why it is not randomly set. The user should set it himself.
You can only read the value of the env var when you are on the host the container runs on or the debug mode leaks something.

from container-healthchecks.

https://docs.djangoproject.com/en/2.0/ref/settings/#secret-key

The secret key has nothing to do with data in the database. It is used for cryptographic signing of dynamic data first and foremost.

There are cases in which you might choose to use the SECRET_KEY for signing static data but this is not recommended and not done by default.

There are many Django apps out there resetting the SECRET_KEY on every reboot to something else, to "delete" the session cache, for example.

from container-healthchecks.

You can read the value of the settings.py by just triggering errors on the web-app. A debug window with a lot of information will open exposing a lot of data, that nobody should know.

That's why you are never supposed to used a Django web app in production with Debug = True.

from container-healthchecks.

Just to clarify, though:
I meant generating a random SECRET_KEY only once, when the container is first created and no SECRET_KEY has been set.

The setting of the SECRET_KEY should happen in form of setting a SECRET_KEY environment variable within the container and then invoking it in the settings.py like so:

First, set the environment variable either in the .bash_rc (or something similar) or, even better, put it in the Gunicorn startup service, like mentioned here: https://stackoverflow.com/a/38192511

Then, invoke the SECRET_KEY by fetching the env-variable in the settings.py:
SECRET_KEY = os.environ['DJANGO_SECRET_KEY']

Before, you should check if such an environment variable is already set within the container, if you don't want to generate a random SECRET_KEY each time you restart the container, but again: This would only result in people needing to relogin, for example.

from container-healthchecks.

Actually you could set all settings.py variables this way.
Then you wouldn't spam new lines, everytime you upgrade the container.

from container-healthchecks.

@Braintelligence When you upgrade the container, the container is deleted due to a new image used so no "double" lines.
Still it doesn't matter if there are duplicate lines, the behavior should be to delete the pod after every change.

from container-healthchecks.

If you upgrade the container while using a volume, since no one in their right mind would want the SQLite (or any other database) to just vanish, if they need to upgrade the container, then your script is just adding duplicate lines to the already existing and preconfigured settings.py.

Do I understand correctly, that you seem to have no interest in providing more security and less DRY in this repo, since you're closing away all the issues, even those that go against basic Django guidelines?

from container-healthchecks.

I'm sorry, I may have misunderstood your intentions, seeing how you incorporated some stuff in commits now.

If you want we can just let some time pass, then I might find the time to incorporate setting all the settings.py variables by container-environment-variables, thus removing the DRY-stuff.

from container-healthchecks.

I have added generation of SECRET_KEY when it is empty. Isn't that what you wanted with this issue and #8 ?

The SECRET_KEY is always (re)generated when it is empty and the container starts, depending on how you see it this either encourages users to set it or leave it empty and lose the sessions on container restarts.

Also a volume should point to the sqlite file/ database files and not the directory where the configs reside in, with that duplication I only see duplication of lines as an issue when your use stop and start on a container.

I don't see why you are saying that I have "no interest" as I added the SECRET_KEY feature and removed virtualenv (which is currently broken but I am working on a fix for that). Is there something I am missing?
Only thing here open from your comments is the "duplicate" lines which I don't really see as an issue as I personally always delete the container and re-run/create it so it starts fresh so there is no data left inside the container (except the data on volume(s)) that may be from a potential security breach that may have happened.

from container-healthchecks.

I just saw your new comment (as my internet didn't show the comment when I started writing my comment).
If the feature as I implemented it isn't after your thoughts, let me know and I'm happy to change it as long as I'm also happy with it too ;)

As written in my above comment, I have added an automatic generation of SECRET_KEY variable and removed the virtualenv (will be fixed ASAP).

from container-healthchecks.

(Glad you saw it now)

Actually I mounted the whole healthchecks folder to a docker volume, so I can upgrade the container whenever I want to. From what I'm accustomed to, this is the basic design principle behind docker apps:

Whenever there's a new version of a container or whenever you want to change environment variables or ports and stuff, you can just kill the container and build it anew. If you have a volume with the settings and database ready, then you can upgrade this way.

This is a basic functionality within Rancher. If I want to change an environment variable, the old container is killed and a new one is spun up.

Currently the SQLite file is living within the /healthcheck folder, so even if I wanted to only mount the folder with the SQLite-file, I'd still have to mount the folder with the settings files in it. Or am I missing something? You could perhaps mount a single file, but I always had problems with doing this in rancher.

If you just invoke all the relevant settings.py variables from within container environment variables, that you set via docker environment variables, then there will never be clutter in there and even if someone got access to the settings.py he would have no clue what the settings in there are.

Sure this has no meaning at all, as long as we run with DEBUG = True in there... I can't seem to find a way of how to get the runserver to work with it being set to False...

from container-healthchecks.

Yes as your wrote for Docker you should only mount the data (sqlite file in this context). There should hopefully be a variable in Healthchecks to change the path of the sqlite file, if not I'm getting creative and think of something to change the path to something better than inside the application code.
This way the sqlite file could be moved to for example /data, then you only mount /data and the application code would normally come (docker style), correctly tagged in form of a docker image like this one.
Currently there are no tags for each HealthChecks version on this repo as I didn't have it on my radar that people are using this image. I will fix that when I have gunicorn working which should hopefully happen latest on the weekend.

Also I will look into improving the docs also by looking into #9.

To summarize this is what I will do now to improve the image on your comments:

1. Move the sqlite file to /data (somewhere else than the application code directory) (this way the config is always regenerated on change for example of the env vars)
2. Improve docs
3. Fix removal of python virtual env
4. Add healthcheck version tags for image

I hope this fully clarifies our misunderstanding now :)

from container-healthchecks.

This sounds great.
Actually I switched to using mysql now, just in case.

I will try to commit a PR with my ideas for the settings.py.

But if we can run this on Gunicorn without having the debug site exposed, then this should be a lot closer to production-ready.

from container-healthchecks.