We no longer link all js by default, so we should do this test with a
css instead (we don't care about that specifics of the dir just that its
in the manifest and in this dir).
It fixes the problem in propagating return_only_media_type_on_content_type
and fixes the corresponding test being ineffective.
The mentioned test addes the following line:
...config.action_dispatch.return_only_media_type_on_content_type = true
to the config and checks if it takes effect. However, in this scenario,
the value is already true before this line.
Moreover, the users are supposed to flip this from true to false in real
situations.
This commit flips the config in the test, making it to fail as
expected. The next commit will fix the failure.
In order for return_only_media_type_on_content_type to appropriately
take effect on ActionDispatch::Response, we want to know when
ActionDispatch::Response is loaded.
As load hooks for ActionDispatch would be too broad, the appropriate
registry is for ActionDispatch::Response itself.
Looking into other examples, a hook name is a full class name in
snake case with `_base` suffix omitted, if any. Therefore, in this case,
:action_dispatch_response seems appropriate.
We are seeing some test failures for this test in #37291. It looks like
what's going on is that Puma has changed the output for this command
between 4.1 and 4.2
Previously:
```
...
* Environment: development
* Listening on tcp://localhost:3000
...
```
Now:
```
...
* Environment: development
* Listening on tcp://127.0.0.1:3000
* Listening on tcp://[::1]:3000
...
```
So to get around this, instead of checking the binding address, just
check for the presence of 'Listening' generally like we do on server
start.
Co-authored-by: eileencodes <eileencodes@gmail.com>
Convert all uses of `db_config.configuration_hash[*]` to use methods
defined on an implementation of `DatabaseConfigurations::DatabaseConfig`.
Since we want to get away from accessing properties directly on the
underlying configuration hash, we'll move here to accessing those values
via the implementations on `DatabaseConfig` (or more specifically,
`HashConfig`).
There are still codepaths that are passing around `configuration_hash`,
and follow-on PRs will address those with the goal of using
configuration objects everywhere up until the point we pass a resolved
hash over to the underlying client.
Co-authored-by: eileencodes <eileencodes@gmail.com>
Eventually we'd like to get rid of this class altogether but for now
this PR reduces the surface area by removing methods from the class and
moving classes out into their own files.
* `adapter_method` was moved into database configurations
* `initialize_dup` was removed because it was only used in tests
* Resolver is now it's own class under connection adapters
* ConnectionUrlResolver, only used by the configurations, is in a class
under DatabaseConfigurations
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Previously in some places we used symbol keys, and in some places we used
string keys. That made it pretty confusing to figure out in a particular
place what type of configuration object you were working with.
Now internally, all configuration hashes are keyed by symbols and
converted to such on the way in.
A few exceptions:
- `DatabaseConfigurations#to_h` still returns strings for backward compatibility
- Same for `legacy_hash`
- `default_hash` previously could return strings, but the associated
comment mentions it returns symbol-key `Hash` and now it always does
Because this is a change in behavior, a few method renames have happened:
- `DatabaseConfig#config` is now `DatabaseConfig#configuration_hash` and returns a symbol-key `Hash`
- `ConnectionSpecification#config` is now `ConnectionSpecification#underlying_configuration_hash` and returns the `Hash` of the underlying `DatabaseConfig`
- `DatabaseConfig#config` was added back, returns `String`-keys for backward compatibility, and is deprecated in favor of the new `configuration_hash`
Co-authored-by: eileencodes <eileencodes@gmail.com>
Currently, autoload paths pass to the watcher as directories. If using evented
watcher, this possibly pass as it is to `Listen`.
But autoload paths include files and `Listen` raise an error when was passed
file. So, it is necessary to classify files and directories correctly.
Fixes#37011.
Previously, we used the migration status to determine whether the test
database(s) needed to be reloaded from the schema. This worked in most
cases, but if a schema.rb was modified outside of migrations or if a
migration was rolled back, it would require a manual db:test:prepare.
This commit updates load_schema to record the SHA1 of the loaded schema
file inside of the ar_internal_metadata table. We can then use this SHA
to determine whether we should reload the schema.
This ensures that the test DB stays exactly in sync with the schema
file, including rollbacks which fixes a test marked TODO.
The `rake db:seed` command was broken for the primary environment if the
application is using multiple databases. We never implemented `rake
db:seed` for other databases (coming soon), but that shouldn't break the
default case.
The reason this was broken was because `abort_if_pending_migrations`
would loop through the configs for all databases and check for
migrations but would leave the last established connection. So `db:seed`
was looking in the wrong database for the table to seed.
This PR doesn't fix the fact that `db:seed` doesn't work for multiple
databases but does fix the default case.
Fixes#36817
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Applications are not supposed to use require_dependency in their own
code if running in zeitwerk mode, and require_dependency was initially
aliased to require with that use case in mind.
However, there are situations in which you cannot control the mode and
need to be compatible with both. There, you might need require_dependency
in case you are being executed in classic mode. Think about engines that
want to support both modes in their parent applications, for example.
Furthermore, Rails itself loads helpers using require_dependency.
Therefore, we need better compatibility.
* read config/webpacker.yml to determine which path to exclude for zeitwerk:check
* fix test errors
* more changes to fix test errors
* refactor webpacker_path
[Andrew Kress + Rafael Mendonça França]
- I made a change in https://github.com/rails/rails/pull/36691 to
delegate route helper to a proxy class.
This didn't take into account that the `url_options` we redefine
in SystemTest would be ignored.
This PR fixes that by definin the url_options inside the proxy
A HTTP feature policy is Yet Another HTTP header for instructing the
browser about which features the application intends to make use of and
to lock down access to others. This is a new security mechanism that
ensures that should an application become compromised or a third party
attempts an unexpected action, the browser will override it and maintain
the intended UX.
WICG specification: https://wicg.github.io/feature-policy/
The end result is a HTTP header that looks like the following:
```
Feature-Policy: geolocation 'none'; autoplay https://example.com
```
This will prevent the browser from using geolocation and only allow
autoplay on `https://example.com`. Full feature list can be found over
in the WICG repository[1].
As of today Chrome and Safari have public support[2] for this
functionality with Firefox working on support[3] and Edge still pending
acceptance of the suggestion[4].
#### Examples
Using an initializer
```rb
# config/initializers/feature_policy.rb
Rails.application.config.feature_policy do |f|
f.geolocation :none
f.camera :none
f.payment "https://secure.example.com"
f.fullscreen :self
end
```
In a controller
```rb
class SampleController < ApplicationController
def index
feature_policy do |f|
f.geolocation "https://example.com"
end
end
end
```
Some of you might realise that the HTTP feature policy looks pretty
close to that of a Content Security Policy; and you're right. So much so
that I used the Content Security Policy DSL from #31162 as the starting
point for this change.
This change *doesn't* introduce support for defining a feature policy on
an iframe and this has been intentionally done to split the HTTP header
and the HTML element (`iframe`) support. If this is successful, I'll
look to add that on it's own.
Full documentation on HTTP feature policies can be found at
https://wicg.github.io/feature-policy/. Google have also published[5] a
great in-depth write up of this functionality.
[1]: https://github.com/WICG/feature-policy/blob/master/features.md
[2]: https://www.chromestatus.com/feature/5694225681219584
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801
[4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy
[5]: https://developers.google.com/web/updates/2018/06/feature-policy
Until Rails 5.2, generators can run same name multi times without destroying.
But Rails 6.0(with Zeitwerk) can't this. In Rails 6.0, an error occurs
due to class name collision check.
The check uses `const_defined?`, which assumes that the autoload object
is also defined.
https://ruby-doc.org/core-2.6.3/Module.html#method-i-const_defined-3F
It did not work until Rails 5.2, but Zeitwerk seems to be able to
correctly check this against the application's code.
However, this is a little inconvenient if want to run the generator
again like mistake an attribute name(need to run `destoy` before).
In order to solve this, this PR adds an option to skip the collision check.
With this option, you can overwrite files just as did until Rails 5.2.
For multiple databases we attempt to generate the tasks by reading the
database.yml before the Rails application is booted. This means that we
need to strip out ERB since it could be reading Rails configs.
In some cases like https://github.com/rails/rails/issues/36540 the ERB
is too complex and we can't overwrite with the DummyCompilier we used in
https://github.com/rails/rails/pull/35497. For the complex causes we
simply issue a warning that says we couldn't infer the database tasks
from the database.yml.
While working on this I decided to update the code to only load the
database.yml once initially so that we avoid having to issue the same
warning multiple times. Note that this had no performance impact in my
testing and is merely for not having to save the error off somewhere.
Also this feels cleaner.
Note that this will not break running tasks that exist, it will just
mean that tasks for multi-db like `db:create:other_db` will not be
generated. If the database.yml is actually unreadable it will blow up
during normal rake task calls.
Fixes#36540
I changed to set CSP nonce to `style-src` directive in #32932.
But this causes an issue when `unsafe-inline` is specified to `style-src`
(If a nonce is present, a nonce takes precedence over `unsafe-inline`).
So, I fixed to nonce directives configurable. By configure this, users
can make CSP as before.
Fixes#35137.
I changed return value of `ActionDispatch::Response#content_type` in #36034.
But this change seems to an obstacle to upgrading. https://github.com/rails/rails/pull/36034#issuecomment-498795893
Therefore, I restored the behavior of `ActionDispatch::Response#content_type`
to 5.2 and deprecated old behavior. Also, made it possible to control the
behavior with the config.
This PR moves the `schema_migration` to `migration_context` so that we
can access the `schema_migration` per connection.
This does not change behavior of the SchemaMigration if you are using
one database. This also does not change behavior of any public APIs.
`Migrator` is private as is `MigrationContext` so we can change these as
needed.
We now need to pass a `schema_migration` to `Migrator` so that we can
run migrations on the right connection outside the context of a rake
task.
The bugs this fixes were discovered while debugging the issues around
the SchemaCache on initialization with multiple database. It was clear
that `get_all_versions` wouldn't work without these changes outside the
context of a rake task (because in the rake task we establish a
connection and change AR::Base.connection to the db we're running on).
Because the `SchemaCache` relies on the `SchemaMigration` information we
need to make sure we store it per-connection rather than on
ActiveRecord::Base.
[Eileen M. Uchitelle & Aaron Patterson]
