I keep getting the error "not authorized" whenever i try to visit:
appname.herokuapp.com/admin_data
I've created an admin.rb file with
AdminData.config do |config|
#comment
config.is_allowed_to_view = lambda {|controller| return true if (Rails.env.development? || Rails.env.production?) }
end
(I know the above following has a safety issue but I'm just trying to get it work before I check for administration.)
I've tried
bundle exec rake assets:precompile
and also
RAILS_ENV=production rake assets:precompile
prior to pushing to heroku but i can't seem to get past that error.
I've followed the instructions from
https://github.com/bigbinary/admin_data
but can't seem to get it to work on production.
On my development machine it works.
http://localhost:3000/admin_data shows everything belonging to my dev environment.
Are you certain that your heroku instance is in production mode? Sometimes instances on Heroku are configured as staging.
Try this:
heroku config --app your_app_name
This will return the config variables of your instance. You will see a variety of config variables. Look for these:
RACK_ENV => production
RAILS_ENV => production
Are they set to production or staging?
Have you read the Production Configuration section of https://github.com/bigbinary/admin_data/wiki/admin_data-security-configuration-for-a-Rails3-application - seems like there are extra steps you need to take when your application is running in production mode.
ah it was a dumb mistake. i was not pushing from my master branch and my app was never being updated
Related
The Heroku documentation at https://devcenter.heroku.com/articles/deploying-to-a-custom-rails-environment says I shouldn't use a staging.rb file to define my staging environment.
It may be tempting to create another custom environment such as “staging” and create a config/environments/staging.rb and deploy to a Heroku app with RAILS_ENV=staging.
This is not a good practice. Instead we recommend always running in production mode and modifying any behavior by setting your config vars.
I think this is terrible advice and conflicts with well-established Rails best practice. However, I'm not here to argue about best practices. I'm here to ask:
Are there any reasons not to use RAILS_ENV=staging on Heroku?
Is there anything that will break if I create a staging.rb file and set the xxx_ENV config vars like this?
heroku config:add RACK_ENV=staging --remote staging
heroku config:add RAILS_ENV=staging --remote staging
No, there isn't anything that will break if you do this.
However, I do think that Heroku is right here (note that I work at Heroku).
It introduces possible differences between your staging and production environments, when the only thing that changes between them should be configuration variables.
Heroku already provides a secure mean of setting configuration variables, with the config:set command.
Using 2 config files means you have to maintain the same configuration twice, and possible can have issues because you updated the configuration correctly in staging, but incorrectly in production.
As a side note, RACK_ENV should only ever have 3 values: production, development and none. See https://www.hezmatt.org/~mpalmer/blog/2013/10/13/rack_env-its-not-for-you.html
You'll get some warnings from Heroku when you deploy, but I can confirm I did run staging apps, with RAILS_ENV=staging, on Heroku. As long as you set the correct environment variables and Gemfile groups, it should just work.
My guess is that the reason they advise not to use custom environments is that they have some operational tooling that assumes your Rails app runs in production environment, but so far I didn't run into issues.
After deploying my app to heroku i get application error. But i do not get stack trace and any other information in browser. Yeah i know i can use heroky -logs but they don't give me information at all.All Ready try to set up ENV=Development. Want to my error pages on heroku will looks like
try this, you can keep track
heroku logs -t
You can catch errors manually and show they at view
Errors catching in Ruby is perfomes via begin, rescue, else, ensure and end
And you are need not catch errors in each method of each controller - you just can add common handler for unhandled exceptions, look here how
On heroku your app runs in production mode. I beleive, the answer for this question should help: Rails - error in production mode
To see development like errors on Heroku you have to run the app in development mode. Heroku sets two config variables RACK_ENV and RAILS_ENV to production by default when you deploy your app to heroku, you can see this in config vars under heroku app settings.
To run your app in development mode set RACK_ENV and RAILS_ENV to development.
You can do this through heroku toolbelt:
heroku config:set RACK_ENV=development --app app-name
heroku config:set RAILS_ENV=development --app app-name
Not to mention but you should set this back to production before giving it to your real users.
I have recently asked a similar question to this but as the problem has moved on slighty I have decided to create a new question - I hope this is the expected approach?
Having pushed my Rails 4 app to Heroku I keep getting an Internal Server Error Page and the error is:
You must set config.secret_key_base in your app's config
This is happening because my .gitignore file includes the config/initializers/secret_token.rb deliberately.
I have installed the Figaro gem so that I could set my secret_key_base as an environment variable for added security. I have checked on Heroku that the key has been set correctly.
My code for the secret_token.rb is as follows:
MyApp::Application.config.secret_key_base = ENV["SECRET_KEY_BASE"]
However, I'm still getting the same issue.
Can anyone help???
I did something simlilar to you that worked, but didn't use Figaro. I based it off this blog post
In summary, here's what I did:
1) remove config/initializers/secret_token.rb from your .gitignore
2) Use this code for your secret_token.rb:
MyApp::Application.config.secret_token = if Rails.env.development? or Rails.env.test?
('x' * 30) # meets minimum requirement of 30 chars long
else
ENV['SECRET_TOKEN']
end
3) commit and re-push
4) set Heroku env variale like:
heroku config:set SECRET_TOKEN=12345.....
Worked as soon as Heroku restarted after the config set.
You can set environment variables on heroku:
https://devcenter.heroku.com/articles/config-vars
You need to set SECRET_KEY_BASE environment variable for heroku with this command:
heroku config:set SECRET_KEY_BASE=value
This may help folks using Rails +4.1:
"When deploying a Rails 4.1+ app, Heroku will specify a SECRET_KEY_BASE on
your app by default." (https://blog.heroku.com/container_ready_rails_5)
In other words you won't have to do anything. You can omit secrets.yml (the standard version that is) from your .gitignore file without fear of losing any production related secrets.
I decided to test my app in the production environment today. It's running fine in test and dev environments. But when I started a mongrel server in production I got a message about assets not being available so I did:
bundle exec rake assets:precompile
Well that got the app booting up but now my images and css are all resolving to 404s. So I think there must be a checklist of things to do to get a Rails 3 app ready for production. I googled a bit but didn't see anything like "make sure you check/do all these things before you switch to prod".
My command to start the server: rails s -e production -p 5000 (because I want to run the prod/test/dev mongrels on the same server right now).
So, what do you do when you switch an app from test to production?
Depending on your webserver you may have to change the following setting in config/environments/prodcution.rb from:
config.serve_static_assets = false
To:
config.serve_static_assets = true
What is the best way to automatically clear Memcached when I deploy my rails app to Heroku?
I'm caching the home page, and when I make changes and redeploy, the page is served from the cache, and the updates aren't incorporated.
I want to have this be totally automated. I don't want to have to clear the cache in the heroku console each time I deploy.
Thanks!
I deploy my applications using a bash script that automates GitHub & Heroku push, database migration, application maintenance mode activation and cache clearing action.
In this script, the command to clear the cache is :
heroku run --app YOUR_APP_NAME rails runner -e production Rails.cache.clear
This works with Celadon Cedar with the Heroku Toolbelt package. I know this is not a Rake-based solution however it's quite efficient.
Note : be sure you set the environment / -e option of the runner command to production as it will be executed on the development one otherwise.
Edit : I have experienced issues with this command on Heroku since a few days (Rails 3.2.21). I did not have time to check the origin the issue but removing the -e production did the trick, so if the command does not succeed, please run this one instead :
heroku run --app YOUR_APP_NAME rails runner Rails.cache.clear
[On the Celadon Cedar Stack]
-- [Update 18 June 2012 -- this no longer works, will see if I can find another workaround]
The cleanest way I have found to handle these post-deploy hooks is to latch onto the assets:precompile task that is already called during slug compilation. With a nod to asset_sync Gem for the idea:
Rake::Task["assets:precompile"].enhance do
# How to invoke a task that exists elsewhere
# Rake::Task["assets:environment"].invoke if Rake::Task.task_defined?("assets:environment")
# Clear cache on deploy
print "Clearing the rails memcached cache\n"
Rails.cache.clear
end
I just put this in a lib/tasks/heroku_deploy.rake file and it gets picked up nicely.
What I ended up doing was creating a new rake task that deployed to heroku and then cleared the cache. I created a deploy.rake file and this is it:
namespace :deploy do
task :production do
puts "deploying to production"
system "git push heroku"
puts "clearing cache"
system "heroku console Rails.cache.clear"
puts "done"
end
end
Now, instead of typing git push heroku, I just type rake deploy:production.
25 Jan 2013: this is works for a Rails 3.2.11 app running on Ruby 1.9.3 on Cedar
In your Gemfile add the following line to force ruby 1.9.3:
ruby '1.9.3'
Create a file named lib/tasks/clear_cache.rake with this content:
if Rake::Task.task_defined?("assets:precompile:nondigest")
Rake::Task["assets:precompile:nondigest"].enhance do
Rails.cache.clear
end
else
Rake::Task["assets:precompile"].enhance do
# rails 3.1.1 will clear out Rails.application.config if the env vars
# RAILS_GROUP and RAILS_ENV are not defined. We need to reload the
# assets environment in this case.
# Rake::Task["assets:environment"].invoke if Rake::Task.task_defined?("assets:environment")
Rails.cache.clear
end
end
Finally, I also recommend running heroku labs:enable user-env-compile on your app so that its environment is available to you as part of the precompilation.
Aside from anything you can do inside your application that runs on 'application start' you could use the heroku deploy hooks (http://devcenter.heroku.com/articles/deploy-hooks#http_post_hook) that would hit a URL within your application that clears the cache
I've added config/initializers/expire_cache.rb with
ActionController::Base.expire_page '/'
Works sweet!
Since the heroku gem is deprecated, an updated version of Solomons very elegant answer would be to save the following code in lib/tasks/heroku_deploy.rake:
namespace :deploy do
task :production do
puts "deploying to production"
system "git push heroku"
puts "clearing cache"
system "heroku run rake cache:clear"
puts "done"
end
end
namespace :cache do
desc "Clears Rails cache"
task :clear => :environment do
Rails.cache.clear
end
end
then instead of git push heroku master you type rake deploy:production in command line.
To just clear the cache you can run rake cache:clear
The solution I like to use is the following:
First, I implement a deploy_hook action that looks for a parameter that I set differently for each app. Typically I just do this on the on the "home" or "public" controller, since it doesn't take that much code.
### routes.rb ###
post 'deploy_hook' => 'home#deploy'
### home_controller.rb ###
def deploy_hook
Rails.cache.clear if params[:secret] == "a3ad3d3"
end
And, I simply tell heroku to setup a deploy hook to post to that action whenever I deploy!
heroku addons:add deployhooks:http \
--url=http://example.com/deploy_hook?secret=a3ad3d3
Now, everytime that I deploy, heroku will do an HTTP post back to the site to let me know that the deploy worked just fine.
Works like a charm for me. Of course, the secret token not "high security" and this shouldn't be used if there were a good attack vector for taking your site down if caches were cleared. But, honestly, if the site is that critical to attack, then don't host it on Heroku! However, if you wanted to increase the security a bit, then you could use a Heroku configuration variable and not have the 'token' in the source code at all.
Hope people find this useful.
I just had this problem as well but wanted to stick to the git deployment without an additional script as a wrapper.
So my approach is to write a file during slug generation with an uuid that marks the current precompilation. This is impelmented as a hook in assets:precompile.
# /lib/tasks/store_asset_cacheversion.rake
# add uuidtools to Gemfile
require "uuidtools"
def storeCacheVersion
cacheversion = UUIDTools::UUID.random_create
File.open(".cacheversion", "w") { |file| file.write(cacheversion) }
end
Rake::Task["assets:precompile"].enhance do
puts "Storing git hash in file for cache invalidation (assets:precompile)\n"
storeCacheVersion
end
Rake::Task["assets:precompile:nondigest"].enhance do
puts "Storing git hash in file for cache invalidation (assets:precompile:nondigest)\n"
storeCacheVersion
end
The other is an initializer that checks this id against the cached version. If they differ, there has been another precompilation and the cache will be invalidated.
So it dosen't matter how often the application spins up or down or on how many nodes the worker will be distributed, because the slug generation just happens once.
# /config/initializers/00_asset_cache_check.rb
currenthash = File.read ".cacheversion"
cachehash = Rails.cache.read "cacheversion"
puts "Checking cache version: #{cachehash} against slug version: #{currenthash}\n"
if currenthash != cachehash
puts "flushing cache\n"
Rails.cache.clear
Rails.cache.write "cacheversion", currenthash
else
puts "cache ok\n"
end
I needed to use a random ID because there is as far as I know no way of getting the git hash or any other useful id. Perhaps the ENV[REQUEST_ID] but this is an random ID as well.
The good thing about the uuid is, that it is now independent from heroku as well.