Problematic Default Configuration for Devise.secret_key

Currently the default behavior when generating a Solidus application using the generator and including Solidus Auth Devise is to set the Devise.secret_key to a random value at application boot.

This is handled by lib/generators/solidus/auth/install/templates/config/initializers/devise.rb and creates the following code in config/initializers/devise.rb.

# frozen_string_literal: true

Devise.secret_key = SecureRandom.hex(50).inspect

This creates problematic behavior, because the secret key base used to generate password reset tokens uses an ephemeral key which is lost on application reboot, and is not known across different instances of the same application (for example multiple Kubernetes pods running the app). As a result, all password reset links are invalidated when the application is restarted, and password reset links will fail to function if a different replica of the application handles the request to set the password from the replica that initiated the reset.

By default, Devise uses Rails.application.secret_key_base if you do not set Devise.secret_key explicitly which is generally stable across restarts and (if correctly configured) different replicas of the application. Accepting this as the default behavior by not setting Devise.secret_key at all would prevent these problems that the default behavior currently produces.

Solidus Version: 4.3.4

To Reproduce
The behavior is reproduced when creating a new solidus application using the solidus generator.

Start with lib/generators/solidus/auth/install/templates/config/initializers/devise.rb and inspect the Solidus application generator output. Verify that the generated config does not assign an ephemeral Devise.secret_key and that password-reset behavior uses the stable Rails application secret key base.