Deprecation - Rails.application.secrets

[BroiSatse]

Environment

• Ruby 3.2.2
• Rails 7.1.1
• Devise 4.9.3

Current behavior

Starting an application yields deprecation warning on Rails.application.secrets

Expected behavior

No deprecation warning

[BroiSatse]

Issue is caused by Devise::SecretKeyFinder#find method. Devise is currently trying to find a secret key in credentials, secrets and config before checking the application itself, deprecation warning is triggered on every call to Rails.application.secrets.

Is there any reason why we need SecretKeyFinder any more? I assume it was required to cover various rails version, but now devise dropped support for rails < 6.0, so there's always secret_key_base on application object

[lordsynergy]

Hello,

I wanted to report that I am facing a similar issue with the deprecation warning related to Rails.application.secrets. However, this issue appears for me only when running tests.

My environment details:

• Ruby: 3.2.2
• Rails: 7.1.1
• Devise: 4.9.3

I would appreciate any assistance or recommendations on how to resolve this issue.

Kind regards, George S.

[BroiSatse]

For those looking for an immediate fix, it is possible to monkey_patch around the issue. Add the following in your initializers/devise.rb:

class Devise::SecretKeyFinder
  def find
    @application.secret_key_base
  end
end

[ckraybill]

No monkey patching needed, you can just configure Devise's secret_key in your setup:

Devise.setup do |config|
  config.secret_key = ENV['SECRET_KEY_BASE'] # or whatever is your preferred method
end

Devise will only want to use the SecretKeyFinder if it isn't already configured.

[jrochkind]

Thanks @ckraybill, that's nice! It looks like you can also do this to keep it DRY where you are specifying the secret key base, whether it's ENV or elsewhere:

Devise.setup do |config|
  config.secret_key = Rails.application.secret_key_base
end

[dan-jensen]

For clarity, here's the PR to resolve this issue: https://github.com/heartcombo/devise/pull/5645. (There were a couple PRs, it seems we should focus on this one.)