SECRET_KEY is hardcoded into production settings

[tobyaharris]

As we move towards a published production environment it's time to use a secret key properly.

I've copied in setup_keys.sh from another repo that uses django, which generates a key into a file django_secret_key (no extension)

Experiments including:

with open('./django_secret_key') as f:  
    SECRET_KEY = f.read().strip()

to replace the hardcoded value in settings.py haven't worked yet, but need to - what do other solutions do?

[tobyaharris]

Inspiration from another solution: Declare it as an env file in docker-compose.

[tobyaharris]

Not working - in inventory_project/settings.py, SECRET_KEY = os.getenv("SECRET_KEY") returns without error, but on inspection the value is None.

Surprising as it's setup exactly the same as Scrap Monitoring. setup_keys.sh runs well, there is a file django_secret_key as expected in the clone root dir (alongside docker-compose.yml, which is looking for it as per above.)

[tobyaharris]

In any case we need a clean failure if a user forgets to run setup_keys.sh

[tobyaharris]

The issue appears to be that the env file only becomes available at runtime, but it is being looked for at build time. Moving the migrate command from Dockerfile to docker-compose.yml might help.

[tobyaharris]

Resolved in #19

[tobyaharris]

In any case we need a clean failure if a user forgets to run setup_keys.sh

This is outstanding. If we find motivation to work on this in the future, it can become a new issue.