11–20 of 60 posts
> if Rails.env.development? or Rails.env.test? I hate code like this that is explicitly aware of the environment. The code says what it will do in an environment, rather than the environment saying what the code should do in it.
if ENV['SECRET_TOKEN'].blank? raise 'SECRET_TOKEN environment variable is not set!' end
App::Application.config.secret_token = ENV['SECRET_TOKEN']
For one example, see this from a year ago: https://github.com/rails/rails/pull/3777#issuecomment-289375...
> If we ignore them, this means a recently created, pushed and then cloned project is not going to work at all.
Some people replace it with a new file upon deployment, some people use ENV vars, some (most) people never open-source their app, and don't mind employees seeing it...
I personally do https://github.com/hotsh/rstat.us/blob/master/config/initial...
Being generic is hard.
> if Rails.env.development? or Rails.env.test? I hate code like this that is explicitly aware of the environment. The code says what it will do in an environment, rather than the environment saying what the code should do in it.
Something more like the following is probably a better solution: if ENV['SECRET_TOKEN'].blank? raise 'SECRET_TOKEN environment variable is not set!' end App::Application.config.secret_token = ENV['SECRET_TOKEN']
Even better, raise 'SECRET_TOKEN not set! Please refer to the doc in xyz'
So, the specific method for setting is in an "xyz" doc that your team keeps in a SEPARATE location from the code repo.
And, we really need a standard way to do this, or Github pulls / forks will have more friction or bad security when setting up forks.
Also, I really would rather put it in a file, not system env, as the env might be setup different on different systems, & you'd hate to have that env potentially shared in multi-user systems. Files are more reliably locked down.
Eh... Keeping that in the system environment isn't really any better than hardcoded in a file. There's a long history of "do not trust the system environment" when it comes to security so I can't say I'd recommend this. Last I checked it was also fairly trivial to dump this data out of a running program... Unless you're grabbing that key out of "secure memory", a HSM or a TPM then its not really particularly secure.
We've had discussions about this several times, and haven't come up with something that's satisfactory as a generic replacement, other than "configuration could probably be improved." For one example, see this from a year ago: https://github.com/rails/rails/pull/3777#issuecomment-289375... > If we ignore them, this means a recently created, pushed and then cloned project is not going to work at all. Some people repla…
> some (most) people never open-source their app, and don't mind employees seeing it...
One of my concerns is that people believe it's only a risk if they ever open source their application. While most apps don't have to worry about a motivated attacker in reality, the risk isn't simply secure or unsecure.
It's more a case of 'more difficult' vs. 'much easier' to compromise. I fear many engineers don't think of securing their apps like this. I know I've only recently begun to understand this way of thinking about security and it's changed the way I code.
We've had discussions about this several times, and haven't come up with something that's satisfactory as a generic replacement, other than "configuration could probably be improved." For one example, see this from a year ago: https://github.com/rails/rails/pull/3777#issuecomment-289375... > If we ignore them, this means a recently created, pushed and then cloned project is not going to work at all. Some people repla…
To a newbie like me, everything will "just work" in development. In production, I'll get a pretty explicit/precise error message.
I haven't run into any problems using that method. Does anyone see a reason to prefer environment variables over it?
Eh... Keeping that in the system environment isn't really any better than hardcoded in a file. There's a long history of "do not trust the system environment" when it comes to security so I can't say I'd recommend this. Last I checked it was also fairly trivial to dump this data out of a running program... Unless you're grabbing that key out of "secure memory", a HSM or a TPM then its not really particularly secure.
If it doesn't show up in a repo file then it is a bit better.
Here's a great example of the repo file checkin fail though: http://bit.ly/10dLiDz
> Knowing the secret token allows an attacker to trivially impersonate any user in the application. Worse. Knowing the secret token allows an attacker to trivially execute code in your application. Don't ever let your secret token become public knowledge, and if it does, you need to change it straight away.