What is the purpose of this Rails config setting...
config.action_controller.consider_all_requests_local = true
It's set to true by default in config/environments/development.rb.
Thanks,
Ethan
Non-local requests result in user-friendly error pages. Local requests, assumed to come from developers, see a more useful error message that includes line numbers and a backtrace. consider_all_requests_local allows your app to display these developer-friendly messages even when the machine making the request is remote.
At development level we set:
consider_all_requests_local set = true
because developer needs to take a look at full error showing layout/view as you can see in the image below.
But at production level, we don't need to show our internal coding bug so we set false:
config.consider_all_requests_local = false
Related
Rails v5.1.6, Ruby 2.3.3
In my newly-generated Rails application, I see the following code in config/environments/test.rb:
# Disable request forgery protection in test environment.
config.action_controller.allow_forgery_protection = false
config.action_mailer.perform_caching = false
All the related sections of code in this file seem to be delimited by comments, including this section. To me, that implies the two uncommented lines of code are related to each other, and are both meant to fall under the umbrella of request forgery protection (as stated in the comment).
I get why a line such as action_controller.allow_forgery_protection would fall under this category, but it isn't readily apparent to me why action_mailer.perform_caching would do so. Most of the other lines of code are straightforward (especially with their respective comments), but nothing in this file makes this particular line of code any clearer, at least to me.
What is the connection between caching emails and request forgery? Or am I interpreting the delimiting incorrectly, i.e. are emails in fact not related to request forgery?
Update: I suspect this 2nd scenario might be the case (i.e. the two concepts might be unrelated), since in config/environments/production.rb, this same line of code is found in found in a config section which is unrelated to request forgery:
# Use a real queuing backend for Active Job (and separate queues per environment)
# config.active_job.queue_adapter = :resque
# config.active_job.queue_name_prefix = "wms_#{Rails.env}"
config.action_mailer.perform_caching = false
However, a 2nd opinion wouldn't go amiss.
They're unrelated. You can see in the current (future 6.0) template source they're intended to be much more clearly separated, with blank lines and now even another also-unrelated setting in between.
The missing blank line seems to be a formatting error introduced during Rails 5.0 development, where perform_caching was added, and (because the template format makes it less clear) a preceding blank was not.
Comparing the generated config/environments/test.rb between 5.1.6 and 5.2.1 confirms it looks better in the newer version (though that line does stand out as being one of the only settings in that file without a matching comment).
We are load testing an application. I just want to check how it behaves if it hits database every time a request is made. I want to stop all type of caching temporarily. Is there a to do this?
Thanks,
Imran
In development mode by default no caching performed. You can adjust caching in config/environments/development.rb and config/environments/production.rb
E.g., there're following values in the production config by default
config.cache_classes = true
config.action_controller.perform_caching = true
config.action_view.cache_template_loading = true
I was just wondering and didn't find explicit response on what in the model class (ActiveRecord) is cached when setting config.cache_classes to true ?
Could someone tell me or point me to the doc I didn't found ?
Thanks
It determines whether or not your application classes are reloaded on each request. If it's true, you have to restart your server for code changes to take effect (i.e. you set it to true in production, false in development.)
Documentation is here.
What is cached when using config.cache_classes = true
It responsible for two thing in rails 4
1. It prevent class reloading between requests.
2. It ensure Rack::Lock in not included in middleware stack, so
that your thread don't get locked.
This is probably very simple but I can't figure out why I get no error pages.
First off, I'm using Heroku for hosting, so it's definitely in production mode.
If I set the line "config.action_controller.consider_all_requests_local" set to true, I get a detailed error message but otherwise, I get a completely 100% blank screen. If I view the source, also blank.
All my 404,422,500.html files are in public and I haven't touched them.
And they seem to work on my local machine if I start in production mode there. So it must have to do with Heroku? Any ideas?
The logs tell me nothing useful.
Below is the details of the production.rb file
config.cache_classes = true
#ActionMailer::Base.delivery_method = :sendmail
Paperclip.options[:command_path] = "/usr/bin/"
# Don't care if the mailer can't send
config.action_mailer.raise_delivery_errors = false
# set delivery method to :smtp, :sendmail or :test
config.action_mailer.delivery_method = :smtp
# Full error reports are disabled and caching is turned on
config.action_controller.consider_all_requests_local = false
config.action_controller.perform_caching = true
config.action_view.cache_template_loading = true
I don't think Heroku uses the .html files like Passenger or Mongrel do. You may need to catch and handle your own exceptions through two basic mechanisms:
Create an exception handler with rescue_from in your ApplicationController for anything that might explode, both specifically and up to and including Object.
Create a default route to catch anything that isn't otherwise routed.
If you bust out of your routing table, or trigger a "500" error, it's because of exceptions. These need to be handled or you'll get a blank screen unless the web server is configured otherwise.
Apache can be configured to do this with the ErrorDocument directive.
In my config/environments/development.rb I have the following line:
config.action_controller.consider_all_requests_local = true
which means I should get all the ugly error stuff when in development environment. But for some reason my app has suddenly started giving me the pretty error page you're supposed to see on production.
Is there possibly some place where this may have been over-ridden? Other people are working on the project as well so maybe one of them did something to cause it.
Old post, but just in case someone finds this like I did ...
I'm pretty sure that when the
config.action_controller.consider_all_requests_local = true
is set, local_request? is never called.
I would dump the config value at runtime and see what it is.
How do I access a Rails configuration value during runtime?
(in rails 3.2)
config.consider_all_requests_local = true
Someone might be overriding the local_request? (api) method somewhere, it's a way to always show the proper error page.
I just answered someone else's question on how to override it. You basically just would put a method in one of the controllers (like ApplicationController) like this:
def local_request?
false
end
So, possibly someone used that somewhere. Do a full project search in textmate or using grep.
This just happened to me and it turned out it was just because I had special characters in the page I was trying to load. I added # encoding: utf-8 to the top of the file with the special characters and everything worked.