The documentation on ActiveSupport::MessageVerifier used the “sensitive data” string as an example; that wording might induce the developer to think we’re dealing with encryption, while the payload is actually only Base64 encoded and is not protected at all.
We also improve the documentation on ActiveRecord::SignedId, which uses MessageVerifier and thereby will also expose the ID as encoded cleartext, making explicit that it’s not encryption, only signing.
Lastly, we refer the developer to MessageEncryptor if the payload needs to be encrypted.
* Fix typo in `global_executor_concurrency` error message
* removed `using` and replace multi_thread_pool with `:multi_thread_pool`
Co-authored-by: Petrik de Heus <petrik@deheus.net>
---------
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
In Rack 3.1, using invalid cookie keys was deprecated and in Rack 3.2,
using an invalid cookie key will raise an exception.
Escaping cookie keys is non-standard behaviour and is not understood by
clients, e.g. `document.cookies` will contain escaped keys. It also
doesn't round-trip correctly, as in, setting a header with a given name
won't have the same name in subsequent requests. In addition, the
escaping / unescaping behaviour in previous versions of Rack
[caused a security issue](https://github.com/advisories/GHSA-j6w9-fv6q-3q52).
When the `content` attribute is set for Action Text attachments, Trix
shows this content.
1ac6d40d36a07b48a67bc7f8627fd1f92bffcb14 introduced sanitizing the
`content` attribute of ActionText::Attachable::ContentAttachment.
However, it would also set the `content` attribute when it isn't
present. Instead of showing the image preview, Trix would use the
empty `content` attribute resulting in missing previews for images.
If the value is already a local time, there's no difference, so no need
to warn.
Correspondingly, avoid calling to_time in the handful of places we were
using it internally: it's easy to do, and we know we don't care about
the zone.
This is a partial revert of #41083.
`puma.rb` may update by users, but Rails has improved `puma.rb` sometimes.
For example, 06d614ada9e4609ff83659e842f48af3232a03a5 and f719787c582839fd2fcd886d70b43da3ddad2ceb.
To allow users to know those improvements, I think we should update
`puma.rb` by `app:update`.
The [deprecated secrets removal][1] ended up removing a bit of
non-deprecated functionality related to config.secret_key_base:
- the original implementation prioritized the value of
config.secret_key_base over other sources in all environments
- if unset, the value of config.secret_key_base would be updated to
whichever fallback value was found
The new implementation only sets config.secret_key_base to a fallback
value when Rails.env.local?, and never considers it at all in
production.
This commit aims to restore this missing functionality as well as
simplify the implementation:
- Rails.application.secret_key_base now always delegates to
config.secret_key_base (like the pre-secret-removal implementation)
- secret_key_base validation was moved from the reader to the writer
- config.secret_key_base now handles setting itself to a fallback value
when unset
- In addition, generate_local_secret was simplified because it
previously did 3 things: file manipulation, setting
config.secret_key_base, and returning a value. Now it only creates the
file if necessary and returns the value stored in it
The new implementation has an additional benefit, which is that manually
set config.secret_key_base values are now validated, whereas previously
only fallback values were validated.
[1]: 0c76f17f2dbf0d7ad90c890e6f334743cacce41f
Co-authored-by: Petrik <petrik@deheus.net>
Review and improve Action View Overview guide. [ci-skip]
* Samples that use Proc.new {} can likely be simplified to just use proc {}
* Link to the validations guide where we mention it under conditional callbacks
* after_find callbacks are also triggered by a few other methods: take, sole, find_by!
* We could potentially add some more examples on different types of callbacks that aren't there.
* Updated some sections for clarity
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
Co-authored-by: hatsu <hajiwata0308@gmail.com>
Previously if `assert_difference` called with a proc fails, the inspect
output of the proc object was shown. This is not helpful to identify
what went wrong.
With this commit we leverage the experimental
`RubyVM::AbstractSyntaxTree` api of MRI to print the source code of the
proc that was passed to `assert_difference`. On all other platforms the
behavior stays the same.
The same applies to `assert_changes`.
Before:
```
(called from Rails::ConsoleMethods.include at /home/zzak/code/rails/railties/lib/rails/console/methods.rb:6)
```
After:
```
(called from block in <class:Engine> at /home/zzak/.rbenv/versions/3.4.0/lib/ruby/gems/3.4.0+0/bundler/gems/mission_control-jobs-7295d75ed735/lib/mission_control/jobs/engine.rb:73)
```
Co-authored-by: Wojciech Wnętrzak <w.wnetrzak@gmail.com>
Add examples and explain that RecordNotDestroyed triggered by throwing
:abort in callbacks.
Co-authored-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>