You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is that the source code for ActiveSupport::KeyGenerator defines a default SHA1 hash digest class if the configuration hash digest class have not been set up.
It means that using this KeyGenerator during application initialization (with SHA1) differs from using it after initialization (with SHA256).
Steps to reproduce
In any initializer file, print the hash digest class for ActiveSupport::KeyGenerator, let's say in app/config/initializers/digest_class.rb
pActiveSupport::KeyGenerator.hash_digest_class
Then open a rails console in your local environment with config.eager_load = true
=> The initializer will print SHA1.
But if you print the same code in the console, it will print SHA256.
Expected behavior
I would expect the KeyGenerator to have the same behaviour during and after initialization.
Because for instance, if we generate a key in an initializer using ActiveSupport::KeyGenerator#generate_key, it will be a key generated with SHA1 hash digest class whereas we expect it to be generated with a SHA256 hash digest class.
Is there a reason why the hash digest class is set in an after_initialize ?
System configuration
Rails version:
7.0.7
Ruby version:
3.0.6
The text was updated successfully, but these errors were encountered:
@zzak I understand how initialization works. I just wonder why it necessarily needs to be done in an after_initialize ? As long as we want to have SHA256 as default hash_digest_class, why don't we set that property before initialization so that we can use it during initialization without change of behaviour ?
Since rails 7.0, default hash digest class for
ActiveSupport::KeyGenerator
is SHA256.This SHA256 hash digest class is set through configuration in an
after_initialize
as found in ActiveSupport railtie.The problem is that the source code for
ActiveSupport::KeyGenerator
defines a default SHA1 hash digest class if the configuration hash digest class have not been set up.It means that using this
KeyGenerator
during application initialization (with SHA1) differs from using it after initialization (with SHA256).Steps to reproduce
In any initializer file, print the hash digest class for
ActiveSupport::KeyGenerator
, let's say inapp/config/initializers/digest_class.rb
Then open a rails console in your local environment with
config.eager_load = true
=> The initializer will print SHA1.
But if you print the same code in the console, it will print SHA256.
Expected behavior
I would expect the
KeyGenerator
to have the same behaviour during and after initialization.Because for instance, if we generate a key in an initializer using
ActiveSupport::KeyGenerator#generate_key
, it will be a key generated with SHA1 hash digest class whereas we expect it to be generated with a SHA256 hash digest class.Is there a reason why the hash digest class is set in an
after_initialize
?System configuration
Rails version:
7.0.7
Ruby version:
3.0.6
The text was updated successfully, but these errors were encountered: