| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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.
|
|
|
|
| |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
|
|
|
|
|
| |
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
|
|
|
|
|
| |
When the defaults being loaded are the 5.0 or 5.1 we disable generation
of ids with form_with.
|
|
|
|
|
|
|
|
|
|
| |
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.`
|
|
|
|
| |
This basically reverts 618268b4b9382f4bcf004a945fe2d85c0bd03e32
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
- Introduce a method to select default cipher, and maintain backward compatibility
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
environments
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|\
| |
| | |
remove unused requires
|
| |
| |
| |
| | |
Related to 0129ca2eeb6d5b2ea8c6e6be38eeb770fe45f1fa, f7782812f7e727178e4a743aa2874c078b722eef, f9ed83321ac1d1902578a0aacdfe55d3db754219
|
|/
|
|
| |
than a ruby encoding
|
|
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
| |
This commit suppressed
`warning: instance variable @session_store not initialized`.
e5a6f7ee9e951dbe0e4e9ea2c0743b4dfb135c57 introduced these
warnings.
|
|\
| |
| |
| | |
Setup default session store internally, no longer through an initializer
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
initializer
- By default the session store will be set to cookie store with
application name as session key.
- Older apps are not affected as they will have the session store
initializer generated by Rails in older versions, and Rails will not
overwrite the session store if it is already set or disabled.
- But new apps will not have the initializer, instead the session store
will be set to cookie store by default.
- Based on comment by DHH here - https://github.com/rails/rails/issues/25181#issuecomment-222312764.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
set to activerecord session store
- Use keyword args as it is possible to use them now.
- The error message for activerecord-session_store gem was added in 1807384.
- But it was added for a code path which gets called when we try to
**access** the session store, not when we **set** it.
- So the test expecting the exception started failing because now the
session store is set via railtie again **after** setting it first with
:active_record_store in the test.
- As the error is not raised while setting the store to
:active_record_store, the store gets overwritten by railtie and when
we access it via `session_store` while building the default middleware
stack, the exception is not raised.
- This commit moves the code for raising the exception to the path where
we try to set the store.
|
|/
|
|
|
|
|
|
|
|
|
| |
by Rails
- We need to ability to check whether the session store it is set or
not so that we can set it ourselves in an internal initializer.
- We can't rely on return value of `config.session_store` as it can
return `nil` when set to `disabled` and we will accidentally override it
and set to default cookie store.
- So introduced new method which just tells us whether it is set or not.
|
| |
|
|
|
|
|
|
|
| |
This will fix the failures fixed by
41488adbb89a09fa96188486f8414842ff28c848
and keep this new option that is semi-private
outside of the generated configurations
|
| |
|
|
|
|
| |
Misc:
`config.public_file_server.enabled = true` instead `public_file_server.enabled = true`
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, the sole presence of the Listen constant
enabled the evented file watcher (unless listen resorted to
the polling backend).
This way, applications may depend on listen for other stuff
independently of this feature. Also, allows teams with mixed
setups to decide at boot time whether the evented watcher
should be enabled for each particular instance.
|
| |
|
| |
|
|
|
|
| |
behavior
|
|
|
|
|
| |
Railsties tests are broken with this new update checker so we will use
the old one until we have the tests fixed.
|
|
|
|
| |
Also call it `public_server.index_name` so it'll make more sense.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the implementation of the file update checker written
by Puneet Agarwal for GSoC 2015 (except for the tiny version
of the listen gem, which was 3.0.2 in the original patch).
Puneet's branch became too out of sync with upstream. This is
the final work in one single clean commit.
Credit goes in the first line using a convention understood
by the contrib app.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Fix the message by wrapping the value in missing quotes and adding
the missing backtick at the end. Finally, :lipstick: by adding a space
inside the curly braces.
Before:
`config.public_file_server.headers = {'Cache-Control' => public,
max-age=31536000}
Now:
`config.public_file_server.headers = { 'Cache-Control' => 'public,
max-age=31536000' }`
2. Display `static_cache_control` instead of static_cache_control. This
follows what the 2 neighboring methods are doing.
3. Use strip_heredoc to improve the code formatting and readability
like the 2 neighboring methods and wrap to 80 characters.
|
|
|
|
|
|
|
|
| |
As discussed in https://github.com/rails/rails/pull/19135#issuecomment-153385986.
Replaces `serve_static_files` to unify the static options under the `public_file_server` wing.
Deprecates `serve_static_files` accessors, but make them use the newer config internally.
|
|\
| |
| |
| | |
Add basic support for access control headers to ActionDispatch::Static
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now ActionDispatch::Static can accept HTTP headers so that developers
will have control of returning arbitrary headers like
'Access-Control-Allow-Origin' when a response is delivered. They can
be configured through `#config.public_file_server.headers`:
config.public_file_server.headers = {
"Cache-Control" => "public, max-age=60",
"Access-Control-Allow-Origin" => "http://rubyonrails.org"
}
Also deprecate `config.static_cache_control` in favor of
`config.public_file_server.headers`.
|