aboutsummaryrefslogtreecommitdiffstats
path: root/railties/lib/rails/application/configuration.rb
Commit message (Collapse)AuthorAgeFilesLines
* Let Zeitwerk be a dependency of Active SupportXavier Noria2019-02-131-1/+5
| | | | | Zeitwerk is a strong dependency, planned to replace AS::Dependencies. A line in the generated Gemfile does not convey this as much.
* Zeitwerk integrationXavier Noria2019-02-121-1/+12
|
* Subdomains of localhost are safe against DNS rebindingMarc Schütz2019-01-231-1/+1
|
* Remove deprecated `config.secret_token`Rafael Mendonça França2019-01-171-2/+1
|
* Change `SQLite3Adapter` to always represent boolean values as integersRafael Mendonça França2019-01-171-4/+0
|
* Restructure credentials after environment overrides.Kasper Timm Hansen2019-01-141-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow up to: e0d3313 - Revert renames from `encrypted` and `encrypted_file` back to `credentials`. They might be using our Encrypted* generators but from that level of abstraction they're still about credentials. - Same vein: extract a `credentials` method for the `encrypted` local variable. But don't call it `encrypted` just because it uses that under the hood. It's about capturing the credentials. It's also useful in `change_credentials_in_system_editor`. - Remove lots of needless argument passing. We've abstracted content_path and key_path into methods for a reason, so they should be used. Also spares a conspicuous rename of content_path into file_path in other methods. - Reorders private methods so they're grouped into: command building blocks, option parsers, and the generators. - Extracts commonality in the credentials application tests. A tad unsure about this. But I do like that we go with key, content thus matching the command and remove the yield which isn't really needed. - Moves test/credentials_test.rb to beneath the test/application directory. It's a Rails application test, so it should be in there. - Uses `root.join` — a neat trick gleaned from the tests! — and composes the configuration private methods such that the building block is below the callers.
* Move MailDeliveryJob default to 6.0 defaultsGannon McGibbon2019-01-071-0/+4
|
* Send Active Storage jobs to dedicated queues by defaultGeorge Claghorn2019-01-041-0/+5
| | | Match Action Mailbox, which sets a default queue for each of its two jobs.
* Introduce a guard against DNS rebinding attacksGenadi Samokovarov2018-12-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ActionDispatch::HostAuthorization is a new middleware that prevent against DNS rebinding and other Host header attacks. By default it is included only in the development environment with the following configuration: Rails.application.config.hosts = [ IPAddr.new("0.0.0.0/0"), # All IPv4 addresses. IPAddr.new("::/0"), # All IPv6 addresses. "localhost" # The localhost reserved domain. ] In other environments, `Rails.application.config.hosts` is empty and no Host header checks will be done. If you want to guard against header attacks on production, you have to manually permit the allowed hosts with: Rails.application.config.hosts << "product.com" The host of a request is checked against the hosts entries with the case operator (#===), which lets hosts support entries of type RegExp, Proc and IPAddr to name a few. Here is an example with a regexp. # Allow requests from subdomains like `www.product.com` and # `beta1.product.com`. Rails.application.config.hosts << /.*\.product\.com/ A special case is supported that allows you to permit all sub-domains: # Allow requests from subdomains like `www.product.com` and # `beta1.product.com`. Rails.application.config.hosts << ".product.com"
* Improve deprecation message for enqueue returning falseRafael Mendonça França2018-12-051-0/+4
| | | | | | And make sure new applications in Rails 6.0 has this config enabled. Also, improve test coverage and add a CHANGELOG entry.
* Do not need to mention the method that is being called in the exceptionRafael Mendonça França2018-10-231-1/+1
| | | | | | | What is important to tell is that the database configuration could not be loaded. Fixes #34296.
* Support environment specific credentials file. (#33521)Wojciech Wnętrzak2018-09-191-1/+25
| | | | | | For `production` environment look first for `config/credentials/production.yml.enc` file that can be decrypted by `ENV["RAILS_MASTER_KEY"]` or `config/credentials/production.key` master key. Edit given environment credentials file by command `rails credentials:edit --environment production`. Default behavior can be overwritten by setting `config.credentials.content_path` and `config.credentials.key_path`.
* Drop load_database_yaml and fix testEileen Uchitelle2018-08-291-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | We originally did the whole `load_database_yaml` thing because this test wasn't cooperating and we needed to finish the namespaced rake tasks for multiple databases. However, it turns out that YAML can't eval ERB if you don't tell it it's ERB so you get Pysch parse errors if you're using multi-line ERB or ERB with conditionals. It's a hot mess. After trying a few things and thinking it over we decided that it wasn't worth bandaiding over, the test needed to be improved. The test was added in #31135 to test that the env is loaded in these tasks. But it was blowing up because we were trying to read a database name out of the configuration - however that's not the purpose of this change. We want to read environment files in the rake tasks, but not in the config file. In this PR we changed the test to test what the PR was actually fixing. We've also deleted the `load_database_yaml` because it caused more problems than it was worth. This should fix the issues described in https://github.com/rails/rails/pull/32274#issuecomment-384161057. We also had these problems at GitHub. Co-authored-by: alimi <aibrahim2k2@gmail.com>
* Purpose Metadata For Signed And Encrypted CookiesAssain2018-08-121-0/+4
| | | | | | | | | | | | | | | | Purpose metadata prevents cookie values from being copy-pasted and ensures that the cookie is used only for its originally intended purpose. The Purpose and Expiry metadata are embedded inside signed/encrypted cookies and will not be readable on previous versions of Rails. We can switch off purpose and expiry metadata embedded in signed and encrypted cookies using config.action_dispatch.use_cookies_with_metadata = false if you want your cookies to be readable on older versions of Rails.
* Turn on performance based copsDillon Welch2018-07-231-3/+1
| | | | | | | | | | | | | | | | Use attr_reader/attr_writer instead of methods method is 12% slower Use flat_map over map.flatten(1) flatten is 66% slower Use hash[]= instead of hash.merge! with single arguments merge! is 166% slower See https://github.com/rails/rails/pull/32337 for more conversation
* Merge pull request #32065 from ↵Kasper Timm Hansen2018-04-021-1/+1
|\ | | | | | | | | sikachu/move-SourceAnnotationExtractor-under-rails-namespec Move SourceAnnotationExtractor under Rails module
| * Move SourceAnnotationExtractor under Rails modulePrem Sichanugrist2018-03-221-1/+1
| | | | | | | | This class should be under Rails module as it belongs to Rails.
* | Refactor configs_for and friendseileencodes2018-03-211-0/+12
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moves the configs_for and DatabaseConfig struct into it's own file. I was considering doing this in a future refactoring but our set up forced me to move it now. You see there are `mattr_accessor`'s on the Core module that have default settings. For example the `schema_format` defaults to Ruby. So if I call `configs_for` or any methods in the Core module it will reset the `schema_format` to `:ruby`. By moving it to it's own class we can keep the logic contained and avoid this unfortunate issue. The second change here does a double loop over the yaml files. Bear with me... Our tests dictate that we need to load an environment before our rake tasks because we could have something in an environment that the database.yml depends on. There are side-effects to this and I think there's a deeper bug that needs to be fixed but that's for another issue. The gist of the problem is when I was creating the dynamic rake tasks if the yaml that that rake task is calling evaluates code (like erb) that calls the environment configs the code will blow up because the environment is not loaded yet. To avoid this issue we added a new method that simply loads the yaml and does not evaluate the erb or anything in it. We then use that yaml to create the task name. Inside the task name we can then call `load_config` and load the real config to actually call the code internal to the task. I admit, this is gross, but refactoring can't all be pretty all the time and I'm working hard with `@tenderlove` to refactor much more of this code to get to a better place re connection management and rake tasks.
* Don't enforce UTF-8 by defaultAndrew White2018-02-271-0/+3
| | | | | | With the disabling of TLS 1.0 by most major websites, continuing to run IE8 or lower becomes increasingly difficult so default to not enforcing UTF-8 encoding as it's not relevant to other browsers.
* Revert "Merge pull request #32075 from eileencodes/delete-default-configuration"eileencodes2018-02-221-1/+0
| | | | | | | | | | This reverts commit 16f279ebd474626577ced858e3626ac4535a33df, reversing changes made to 6c6a30a7c357ce1eafa093d77d2b08684fe50887. The config can be named anything, not just default (although all generated apps will be named default). We can't just delete configs that don't have a database because that will break three-tier configs. Oh well.
* Revert "Reject empty database yamls"eileencodes2018-02-221-1/+1
| | | | | | | | | | | | This reverts commit 0979713abe2e22083e1beca01a1d113408c9ab36. I originally wanted to delete the default config but found out it can be called anything which means the code would blow up in unexpected ways. I thought "cool ill just delete the configs without dbs" and realized that totally 100% breaks the three-tier config. So I'm reverting this and the other commit.
* Merge pull request #32018 from rails/add-nonce-support-to-cspAndrew White2018-02-221-37/+38
|\ | | | | Add support for automatic nonce generation for Rails UJS
| * Add support for automatic nonce generation for Rails UJSAndrew White2018-02-191-37/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because the UJS library creates a script tag to process responses it normally requires the script-src attribute of the content security policy to include 'unsafe-inline'. To work around this we generate a per-request nonce value that is embedded in a meta tag in a similar fashion to how CSRF protection embeds its token in a meta tag. The UJS library can then read the nonce value and set it on the dynamically generated script tag to enable it to execute without needing 'unsafe-inline' enabled. Nonce generation isn't 100% safe - if your script tag is including user generated content in someway then it may be possible to exploit an XSS vulnerability which can take advantage of the nonce. It is however an improvement on a blanket permission for inline scripts. It is also possible to use the nonce within your own script tags by using `nonce: true` to set the nonce value on the tag, e.g <%= javascript_tag nonce: true do %> alert('Hello, World!'); <% end %> Fixes #31689.
* | Reject empty database yamlseileencodes2018-02-221-1/+1
| | | | | | | | | | | | | | | | In #32075 I deleted the default configuration since that's what's generated with the Rails app. Since someone could change the default name instead delete any config that doesn't have a database so we can avoid peppering our Rails tasks with conditionals to deal with invalid database configs.
* | Merge pull request #32075 from eileencodes/delete-default-configurationEileen M. Uchitelle2018-02-211-0/+1
|\ \ | |/ |/| Delete default configuration
| * Delete default configurationeileencodes2018-02-211-0/+1
| | | | | | | | | | | | | | Because of this default configuration we're constantly checking if the database exists when looping through configurations. This is unnecessary and we should just delete it before we need to loop through configurations.
* | Don't accidentally create an empty CSPAndrew White2018-02-191-1/+5
|/ | | | | | Setting up the request environment was accidentally creating a CSP as a consequence of accessing the option - only set the instance variable if a block is passed.
* Do not update `load_defaults` version when running `app:update` (#31951)Yuji Yaginuma2018-02-131-1/+4
| | | | | Incompatible settings are included in the settings set by `load_defaults`. So, I think that target version should be updated by a user when becomes available, and should not be updated with `app:update`.
* Fix `RuntimeError: Unknown version "6.0"`Yuji Yaginuma2018-01-311-0/+3
|
* Use SHA-1 for non-sensitive digests by defaultEugene Kenny2018-01-081-0/+1
| | | | | | Instead of providing a configuration option to set the hash function, switch to SHA-1 for new apps and allow upgrading apps to opt in later via `new_framework_defaults_5_2.rb`.
* Raise an error only when `require_master_key` is specifiedyuuji.yaginuma2017-12-181-1/+3
| | | | | | | | | To prevent errors from being raise in environments where credentials is unnecessary. Context: https://github.com/rails/rails/issues/31283#issuecomment-348801489 Fixes #31283
* Make form_with_generates_ids default value to be falseRafael Mendonça França2017-11-271-4/+0
| | | | | This will keep the behavior of an application with the defaults of a 4.2 or 5.0 application behaving the same when upgrading to 5.2.
* Add DSL for configuring Content-Security-Policy headerAndrew White2017-11-271-33/+39
| | | | https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
* Remove duplicated `form_with_generates_remote_forms` settingyuuji.yaginuma2017-11-261-1/+0
| | | | | When load `5.1` config, `form_with_generates_remote_forms` is set. https://github.com/rails/rails/blob/89a209f1abba5a2320d31c4898dea150c0abd0c0/railties/lib/rails/application/configuration.rb#L86
* Make form_with_generates_ids default in Rails 5.2Rafael Mendonça França2017-11-251-2/+7
| | | | | When the defaults being loaded are the 5.0 or 5.1 we disable generation of ids with form_with.
* Change `form_with` to generates ids by defaultnpezza932017-11-251-0/+1
| | | | | | | | | | When `form_with` was introduced we disabled the automatic generation of ids that was enabled in `form_for`. This usually is not an good idea since labels don't work when the input doesn't have an id and it made harder to test with Capybara. You can still disable the automatic generation of ids setting `config.action_view.form_with_generates_ids` to `false.`
* [Railties] require_relative => requireAkira Matsuda2017-10-211-2/+2
| | | | This basically reverts 618268b4b9382f4bcf004a945fe2d85c0bd03e32
* Use tt in doc for railties [skip ci]Yoshiyuki Hirano2017-08-271-1/+1
|
* Adding frozen_string_literal pragma to Railties.Pat Allan2017-08-141-0/+2
|
* Change sqlite3 boolean serialization to use 1 and 0Lisa Ugray2017-07-111-0/+4
| | | | | | | | | | | | | | | | | | | | Abstract boolean serialization has been using 't' and 'f', with MySQL overriding that to use 1 and 0. This has the advantage that SQLite natively recognizes 1 and 0 as true and false, but does not natively recognize 't' and 'f'. This change in serialization requires a migration of stored boolean data for SQLite databases, so it's implemented behind a configuration flag whose default false value is deprecated. The flag itself can be deprecated in a future version of Rails. While loaded models will give the correct result for boolean columns without migrating old data, where() clauses will interact incorrectly with old data. While working in this area, also change the abstract adapter to use `"TRUE"` and `"FALSE"` as quoted values and `true` and `false` for unquoted. These are supported by PostreSQL, and MySQL remains overriden.
* Protect from forgery by defaultLisa Ugray2017-07-101-0/+4
| | | | | | | | Rather than protecting from forgery in the generated ApplicationController, add it to ActionController::Base by config. This configuration defaults to false to support older versions which have removed it from their ApplicationController, but is set to true for Rails 5.2.
* [Railties] require => require_relativeAkira Matsuda2017-07-011-2/+2
|
* set message_encryptor default cipher to aes-256-gcmAssain2017-06-121-0/+4
| | | | - Introduce a method to select default cipher, and maintain backward compatibility
* AEAD encrypted cookies and sessionsMichael Coyne2017-05-221-0/+4
| | | | | | | | | | | | | | | | This commit changes encrypted cookies from AES in CBC HMAC mode to Authenticated Encryption using AES-GCM. It also provides a cookie jar to transparently upgrade encrypted cookies to this new scheme. Some other notable changes include: - There is a new application configuration value: +use_authenticated_cookie_encryption+. When enabled, AEAD encrypted cookies will be used. - +cookies.signed+ does not raise a +TypeError+ now if the name of an encrypted cookie is used. Encrypted cookies using the same key as signed cookies would be verified and serialization would then fail due the message still be encrypted.
* Use recyclable cache keys (#29092)David Heinemeier Hansson2017-05-181-0/+8
|
* Added a shared section to config/database.yml that will be loaded for all ↵Pierre Schambacher2017-04-261-1/+8
| | | | environments
* Apply the log_level defaultRafael Mendonça França2017-03-271-7/+2
| | | | | | | | Since 4.2 the default log level in production is now debug. We removed the deprecation in c2e865849beadd99866e521a93d733da7d1b5255 but we don't reflected the default value. We are not appling it. Closes #28558
* Start Rails 5.2 developmentMatthew Draper2017-03-221-0/+3
|
* Correctly check whether key is defined in configurationyuuji.yaginuma2017-03-191-3/+3
| | | | | | | | | | | | | It can not check correctly with `defined?` ```ruby irb(main):001:0> Rails.application.config.active_record => {:maintain_test_schema=>true, :belongs_to_required_by_default=>true} irb(main):002:0> defined?(Rails.application.config.active_record) => nil ``` Follow up to #28469
* Track the version-compatible config settings inside railtiesMatthew Draper2017-03-181-0/+28
| | | | | | | | | | | | | | | | Instead of forcing new applications to carry an initializer that just switches things to what their default "should" be, we can handle it internally. The initializer is then only used by upgraders: it shows what the new default would be (commented out), while their upgraded application continues to operate as it did before. Under this model, a multiply-upgraded application could accumulate several new_framework_defaults_*.rb files, for each release series it has traversed. A given release series only needs to generate the latest, though, because we don't support `rails app:upgrade` while skipping releases.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 00:10:13 +0000