When deploying django to heroku why should

(Case1)
SECRET_KEY = os.environ.get("SECRET_KEY", "YBWHGRHH"

INSTEAD OF

(Case2)
SECRET_KEY=os.environ['SECRET_KEY']

In my own view the secret key is been exposed in case 1 but more secured in case2

In case 1 it means the default value you set would be used as secret key if you didn't set a SECRET KEY in heroku's env.

In case 2 because there's no default, an error will be thrown if you fail to set the key in the env

Ajibel:
In case 1 it means the default value you set would be used as secret key if you didn't set a SECRET KEY in heroku's env.

In case 2 because there's no default, an error will be thrown if you fail to set the key in the env

Which one is the best?

gbolly1151:


Which one is the best?

It depends on your choice. I don't know the best, but I have used several patterns. Here is an idea of what I do with Flask:

if os.environ.get('SECRET_KEY'):
........SECRET_KEY = os.environ.get('SECRET_KEY')
else:
........SECRET_KEY = 'SECRET_KEY_ENV_VAR_NOT_SET'
........print('SECRET KEY ENV VAR NOT SET! SHOULD NOT SEE IN PRODUCTION')

But again I think to have a .env file where you set your private keys and read from it is what I have seen many open source projects do. Since you're using heroku, go through their django setup walkthrough. I believe whatever pattern they make use of there is what you should go with.

Ajibel:


It depends on your choice. I don't know the best, but I have used several patterns. Here is an idea of what I do with Flask:

if os.environ.get('SECRET_KEY'):
........SECRET_KEY = os.environ.get('SECRET_KEY')
else:
........SECRET_KEY = 'SECRET_KEY_ENV_VAR_NOT_SET'
........print('SECRET KEY ENV VAR NOT SET! SHOULD NOT SEE IN PRODUCTION')

But again I think to have a .env file where you set your private keys and read from it is what I have seen many open source projects do. Since you're using heroku, go through their django setup walkthrough. I believe whatever pattern they make use of there is what you should go with.

Thanks it is really helpful

I understand that dyno is a virtual file system on which django app are served and can go off anytime, when this happen, do i need to set the config var again to start my app when dyno is on again?

gbolly1151:


Thanks it is really helpful

I understand that dyno is a virtual file system on which django app are served and can go off anytime, when this happen, do i need to set the config var again to start my app when dyno is on again?

I haven't had any experience using heroku in this case but what I know is that since the config var you set from the start are persistent, then you wont need to set a new config var again whenever your app is restarted.

Ajibel:


I haven't had any experience using heroku in this case but what I know is that since the config var you set from the start are persistent, then you wont need to set a new config var again whenever your app is restarted.

Yea thanks...got it now....after reading their doc, i knew that the config var are kept just like the source code. Whenever dyno loads, config var are set in the environment. So no need of setting the config var again

The Heroku key can only be accessed if you have exposed it to the client side. However, if your case is different, then you should approach the setting option and proceed with the config. Here, you should enable this: heroku config: set SECRET_KEY="...". Yes, the Heroku environment is considered highly secure if you keep the key secret.

On the other hand, it is also important that you follow the right method to deploy your application on Heroku. If you are using GitHub, then you can simply go with this source https://blog.back4app.com/deploy-to-heroku/ and it will answer all of your queries about deployment. Also, don't forget to utilize protected places to store keys like Heroku Config Vars and Heroku add-ons.

You should also rotate the keys to avoid unauthorized access. Hopefully, it will also help you.