Renaming test containing flag
Updating other test referencing master branch
Add notice that --master is deprecated, but still working the same as --main
Only set @main if it's nil
Making warn wildcard
I think a hidden aliaes would be just as good
Improving description & fixing rubocop error
Forgot comma
Deprecation warning was kind of hard - so just doing alias for now
rubocop -a
When I was comparing 'defaults' for 6.1 in this method and our configuring
guide, I was confused that some active_storage options are missing.
This change doesn't bring any implementation changes and feels like
a cosmetic change. Please feel free to close this if you think so and don't
see that we could benefit this change.
As mentioned in
https://github.com/rails/rails/pull/40770#issuecomment-748347066 we
should default to SHA256 where SHA1 is used today. This switches over
the ActiveSupport::Digest to use SHA256 for new applications.
It also updates the constants to always refer to and use the OpenSSL
constants as well, as also discussed in that PR.
This change allows for configuration of the hash digest that is used in
the key generator for key derivation.
SHA1 is an outdated algorithm and security auditors tend to frown on
its usage. By allowing this to be configured, it becomes possible to
move to a more up to date hash mechanism.
While I don't think this has any current relevant security implications,
especially not with a proper random secret base, moving away from SHA1
makes conversations with auditors and FIPS compliance checks easier
since the best answer is always that an approved algorithm is used.
A rotation can be built using this change with an approach like the
following for encrypted cookies:
```ruby
Rails.application.config.active_support.key_generator_hash_digest_class = OpenSSL::Digest::SHA256
Rails.application.config.action_dispatch.cookies_rotations.tap do |cookies|
salt = Rails.application.config.action_dispatch.authenticated_encrypted_cookie_salt
secret_key_base = Rails.application.secrets.secret_key_base
key_generator = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000, hash_digest_class: OpenSSL::Digest::SHA1)
key_len = ActiveSupport::MessageEncryptor.key_len
secret = key_generator.generate_key(salt, key_len)
cookies.rotate :encrypted, secret
end
```
This turns the default into using SHA256 but also still accepts secrets
derived using SHA1.
The defaults for new apps is here changed to use SHA256. Existing apps
will keep using SHA1.
In #38495, `ARGV` was isolated to prevent commands from depending on its
contents, which might be indeterminate. However, app templates may
depend on `ARGV`, so populate it before evaluating them.
Fixes#40945.
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
Since #39746, the Spring binstub can be generated without having to run
`bundle install` first, and thus the `skip_bundle` option does not
prevent the Spring binstub from being generated. Therefore, explicitly
set the `skip_spring` option for plugin dummy apps.
Since #40646, `bin/yarn` manually searches `PATH` for the `yarn`
executable. In Windows environments, executables have an `.exe` file
extension, so we must search for `yarn.exe` as well.
Fixes#40942.
PR #39939 added support for the `Link` header being generated
automatically when using `stylesheet_link_tag` and
`javascript_include_tag`. However not everything should be
preloaded, e.g. a link to a legacy IE stylesheet has no need to be
preloaded because IE doesn't support the header and in some browsers it
will trigger the preload even though it's not used since it's inside an
IE conditional comment. This leads to increased bandwith costs and
slower application performance.
To allow more flexibility for sites that may have complex needs for the
`Link` header this commit adds a configuration option that disables it
completely and leaves it up to the application to decide how to handle
generating a `Link` header.
Because Bundler is a default gem, `require "bundler"` by itself will
load the default version of the gem, instead of the most recent version.
This can cause Rails commands to produce warnings like the following:
> Warning: the running version of Bundler (2.1.4) is older than the
> version that created the lockfile (2.2.2). We suggest you to upgrade
> to the version that created the lockfile by running
> `gem install bundler:2.2.2`.
Adding `gem "bundler"` allows the most recent version of the gem to be
loaded.
Based on discussion in https://github.com/rails/rails/issues/40795, it
looks like `yarn:install` is *always* run, even if the Rails project
disabled javascript and there is no `bin/yarn`.
Check for the existence of `bin/yarn` to decide if `yarn:install` should
be run or not.
The check for this is taken from `railties/lib/rails/app_updater.rb`,
where it does the same:
```ruby
options[:skip_javascript] = !File.exist?(Rails.root.join("bin", "yarn"))
```
One reason why it could be missing because Rails was upgraded but `rails
app:update` was not run.
Running `rails app:update:bin` should create it.
refs #40795
We don't need a callback and we should not expose the attribute to the
API given this is only internal.
I also removed the CHANGELOG entry because this is a bugfix for a change
that was not released yet.
When we use `bin/yarn` without original yarn,
the following error will be occurred:
```
bin/yarn:12:in `initialize': no implicit conversion of nil into String (TypeError)
```
This means `executable_path` is `nil`.
To handle missing yarn correctly, checking `executable_path` seems good.
This is a result of my local without yarn.
```
Yarn executable was not detected in the system.
Download Yarn at https://yarnpkg.com/en/docs/install
rake aborted!
```
This commit follows up https://github.com/rails/rails/pull/40646.
`form_with` would generate a remote form by default.
This confused users because they were forced to handle remote requests.
All new 6.1 applications will generate non-remote forms by default.
When upgrading a 6.0 application you can enable remote forms by default by
setting `config.action_view.form_with_generates_remote_forms` to `true`.
