Changes between Initial Version and Version 1 of Ticket #20081, comment 10
- Timestamp:
- May 23, 2014, 10:19:44 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #20081, comment 10
initial v1 3 3 I think `django.conf.Settings()` should generate `SECRET_KEY` based on a new setting called `SECRET_KEY_FILE`. If that setting is empty, `Settings.__init__` will fail in the same way it currently does if `SECRET_KEY` is empty. The new setting for `SECRET_KEY_FILE` can be accompanied by documentation (using comments in settings.py) saying that if the file does not exist it will be auto-generated, along with the caveat that the key must remain the same in multi-server environments. When starting a new project via "startproject", `SECRET_KEY_FILE` should default to an empty string. So whether a dev is running startproject or upgrading, they will be forced to look at the setting and understand what it does. 4 4 5 We could further protect devs from slipping up by storing known value in the database that is hashed using the secret key. This could be set during the auto-generate function. Then, during startup we could check the stored value against the hashed one, and if they don't match raise an exception explaining that if you *know* the secret key must be changed and you understand the implications, then you should manually re-hash that known value in the database.5 We could further protect devs from slipping up by storing known value in the database that is hashed using the secret key. This could be set during the auto-generate function. Then, during startup we could check the stored hash against the known value, and if they don't match raise an exception explaining that if you *know* the secret key must be changed and you understand the implications, then you should manually re-hash that known value in the database. 6 6 7 7 Also the function that generates the key should raise an exception if the file exists. In that case file should have to be removed or changed manually.