Previous discussion: #38412, #38325, 37423e4, 24f9c03
- Rack::Runtime is replaced by FakeRuntime, which is a dummy middleware
that just passes requests on and cannot be used in middleware operations
- Using Rack::Runtime in middleware operations (relative inserts, moves,
etc.) throws a deprecation warning and uses FakeRuntime instead
- if an application adds Rack::Runtime explicitly (use, unshift, etc.),
then the deprecation warning does not happen and FakeRuntime is
ignored
- docs are updated to no longer reference Rack::Runtime
e.g. is the abbreviation for the Latin phrase exempli gratia, meaning “for example.” This abbreviation is typically used to introduce one or more examples of something mentioned previously in the sentence and can be used interchangeably with “for example” or “such as.”
This deprecates `legacy_connection_handling` via the
`connection_handlers` setter. This is called from the ActiveRecord
Railtie on boot and since most applications don't set this themselves
this will prevent the deprecation from being raised multiple times for a
test run or in development.
I've also updated the guides to include a migration path for
applications using the deprecated methods. The majority of applications
won't need to make any changes.
This implements several changes to encourage deterministic encryption to
remain unchanged. The main motivation is letting you define unique
indexes on deterministically-encrypted columns:
- By default, deterministic encryption will always use the oldest
encryption scheme to encrypt new data, when there are many.
- You can skip this default behavior and make it always use the current
encryption scheme with:
```ruby
deterministic: { fixed: false } # using this should be a rare need
```
- Deterministic encryption still supports previous encryption schemes
normally. So they will be used to add additional values to queries, for
example.
- You can't rotate deterministic encryption keys anymore. We can add
support for that in the future.
This makes for reasonable defaults:
- People using "deterministic: true" will get unique indexes working out
of the box.
- The system will encourage keeping deterministic encryption stable:
- By always using oldest encryption schemes
- By forbidding configuring multiple keys
But you can still opt-out of the default if you need to.
Currently, the payload of the unpermitted_parameters.action_controller
events emitted by StrongParameters does not provide enough information for
developers to understand which controller and action received the
unpermitted parameters. This PR modifies ActionController::Parameters to
allow callers to specify a "context" which is included in the logging
payload.
*Implementation Strategy*
Since the ActionController::Parameters class is only loosely coupled
with controllers and can technically be used in any context, this PR
expects the caller to provide logging context.
Since StrongParameters is caller in Rails and has access to the
request object I chose to provide a payload similar to the
start_processing.action_controller event.