-
Notifications
You must be signed in to change notification settings - Fork 303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate a secret key file, and load SECRET_KEY from said file. #4494
Conversation
@@ -314,8 +314,22 @@ | |||
USE_L10N = getattr(local_settings, "USE_L10N", False) | |||
|
|||
# Make this unique, and don't share it with anybody. | |||
SECRET_KEY = getattr(local_settings, "SECRET_KEY", | |||
"8qq-!fa$92i=s1gjjitd&%s@4%ka9lj+=@n7a&fzjpwu%3kd#u") | |||
SECRET_KEY_FILE = os.path.join(USER_DATA_ROOT, "secretkey.txt") |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
Why the backport for 0.14? |
Sorry, why is this not a backport but straight for 0.14? |
re: backport -- I just plan to cherry pick this single commit to 0.15. Unless you have other preferred method of propagating this change? |
|
f.flush() | ||
|
||
if not os.path.exists(SECRET_KEY_FILE): | ||
generate_secret_key() |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
Looks good on my side, but made one suggestion for robustness/pythonicness. |
f.write(key) | ||
f.flush() | ||
|
||
if not os.path.exists(SECRET_KEY_FILE): |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
084f69e
to
b608baa
Compare
@jamalex @benjaoming comments addressed. Main changes:
|
@benjaoming added |
Looks good to me -- might be good to test 1 or 2 weird edge cases before merging. |
Tried with
It's expected behaviour. |
Generate a secret key file, and load SECRET_KEY from said file.
Fixes #4213. We already have said vulnerability wherein the SECRETT_KEY is both public and the same for each installation. With the introduction of sessions-in-cookies it's a double whammy.
So now the solution is to create a secret key file for each installation if it's not detected, and load that as the value of SECRET_KEY.
Assigning @jamalex, but @benjaoming please take a look too.