Closed marthamareal closed 3 years ago
@marthamareal for the Django secret key we could adopt the option from the startproject command to obatin a random key at build time. I guess we can do something like:
SECRET_KEY='{{secret_key}}'
here
btw we still have the problem with the OAUTH2 secrets, that must be set manually.
@marthamareal for the Django secret key we could adopt the option from the startproject command to obatin a random key at build time. I guess we can do something like:
SECRET_KEY='{{secret_key}}'
here
@giohappy I have updated the PR and added the command to randomly generate the secrete key in the ReadMe
btw we still have the problem with the OAUTH2 secrets, that must be set manually.
should we also use placeholders in variables OAUTH2_CLIENT_ID
and OAUTH2_CLIENT_SECRET
should we also use placeholders in variables OAUTH2_CLIENT_ID and OAUTH2_CLIENT_SECRET
When I say secrets I mean any private information. So yes, OAUTH2 for sure. A note must be added to the README to remind to assigna value to the .env file for these settings.
should we also use placeholders in variables OAUTH2_CLIENT_ID and OAUTH2_CLIENT_SECRET
When I say secrets I mean any private information. So yes, OAUTH2 for sure. A note must be added to the README to remind to assigna value to the .env file for these settings.
I have updated the variables also DEFAULT_FROM_EMAIL
inclusive.
I would replace the secrets with asterisks inside the nev sample, and say to set valid values for these settings inside the docs. Otherwise most of the deployments will end by using the same secrets.
What do you think @etj?