I’ve set the environment variable RACK_ENV to staging via heroku_san’s configuration file (as well as manually).
When listing all ENV variables, it shows correctly as being set to "staging". If I check via the console I’m getting a correct result as well.
However, if I log it within my application_controller, it appears to be "production". Any idea why and how to correct this?
RAILS_ENV is set to "production". I’m guessing that this might cause the problem. Can’t these two differ from each other?
Rails looks for RAILS_ENV first, then for RACK_ENV. I guess, Heroku sets RAILS_ENV to production by default and it takes precedence over RACK_ENV. Try to set RAILS_ENV environment variable to "staging" directly.
And if that doesn't work, you should log ENV in your application controller, so that we can see what are all the environment variables from inside.
Related
I deleted secrets.yml and created credentials.yml.enc.
Locally I am using master.key, and in production I don't have any master key, only a RAILS_MASTER_KEY set as an environment variable.
On Heroku, if I run Rails.application.secrets I get:
{:secret_key_base=>nil, :secret_token=>nil}
and if I run Rails.application.credentials I do in fact see my secret_key_base.
However, locally... if I run the same commands, I DO see secret_key_base when calling Rails.application.secrets.
My main concern is that rails is going to have an empty secret_key_base in production which would be used to encrypt sessions and all kinds of critically important security things. I'm trying to verify that it actually does have the key set.
I'd love a way to 100% confirm that it's working in production, and that it's not blank. Is there some method I can call to check which doesn't rely on calling it via the methods above?
The SECRET_KEY_BASE is stored as an environment variable on Heroku. You can either view these in the interface by going to the settings for that dyno or you can do it in the terminal:
heroku run bash
then
env | grep SECRET_KEY_BASE
If you do not see it there may be an issue but you can generate a new one for Heroku and set it in the environment variables (see Rails.application.key_generator)
I am trying to secure my app properly by setting environment variables. I am doing it with figaro gem. I am not using heroku, just a vps I setup by myself.
Now on development all works good and makes sense. application.yml contains hardcoded database passwords which are not on database.yml anymore. application.yml is not pushed on repository and passwords are not shared. All good.
But I am having hard time making sense of it on production. If I set production section on database.yml with environment variables and then the application.yml is not on the server running on production, how can it possibly work? Or if I set them on another file that is then pushed later on repository, I just moved harcoded passwords from a file to another and are still accessible. Or are environment varibales supposed to be used only on test and development?
Could someone give me a clear explanation? I have been reading other questions and articles around but I can't make sense of it.
You want to set Unix environment variables in production. Check out this guide which states:
Variables in the config/application.yml file will override environment variables set in the Unix shell.
In other words, in development you would set these variables in application.yml which would then override any values set in Unix. In production, you would set them in the shell and that is where the values would come from. I suggest doing some more general reading regarding environment variables as they are a fundamental part of application development.
I use ENV variables for all environments to set up different components of the stack, i.e. Redis, Memcached, etc.
I load all of these in the config/application.rb file, and before that I ensure that all environment variables are present.
I'm running into a problem now where I run a rake task before these variables are set, and so it fails my test. Rake seems to doing it's share correctly. This leads me to believe all of these variables initializations are in the wrong spot.
Now I'm at a loss as to the best place to instantiate all these services or check for their existence.
Init them right after Bundler.require(*Rails.groups) in your application.rb like this https://github.com/bkeepers/dotenv#note-on-load-order
You can check env variables in Rails console, for example:
ENV['YOUR_ENV_VARIABLE']
I have a Rails application already in production. The guy before set these environment variables:
...
export RACK_ENV=none
export RAILS_ENV=production
...
What does RACK_ENV=none do? I can't find documentation on it anywhere. Do I need to set it in the Rails application or can I just delete that export?
IMHO it's useless.
To find the current environment a Rails app first looks for the RAILS_ENV environment variable, then for RACK_ENV environment variable, then it defaults to 'development'.
If you're using version 1.7 or later of the database_cleaner gem, and your CI server has RACK_ENV set to production like mine did, you'll need to set RACK_ENV to none (or anything other than production) to appease database_cleaner's safeguard that your tests aren't running in production. (Or you could disable the safeguard altogether, but that seems less safe.)
Looking at current rack source, it appears that the only value of RACK_ENV that is meaningful to rack is development, which causes rack to default the host to localhost instead of to 0.0.0.0. So it's foolish to set RACK_ENV to production in the first place, or to check that it's been set to that, but that foolishness has taken root all over.
I have an action which causes an exception in my staging environment, but instead of sending the notification to hoptoad (which it should, the hoptoad test rake task works...), it shows me the standard rails stacktrace page like it does in development.
My staging environment is essentially a copy of my production environment with the only difference being the rails environment being set through passenger.
What could be the cause of this? Where should I be looking? I haven't confirmed that production does the same thing as we don't yet have a proper production environment set up, but I assume it would also act the same way.
Are you sure that your staging instance is running in the correct environment? Have you tried outputting Rails.env somewhere in your views just to make sure?
I only ask because you mentioned seeing a stack trace page, which shouldn't happen in a production environment unless you're making the requests locally, or you have config.action_controller.consider_all_requests_local set to true in your environment config.