Devise: Devise 4.4.2 now requires secret key to be set that worked without in 4.4.1

[remomueller]

Environment

• Ruby 2.5.0
• Rails 5.2.0.rc1
• Devise 4.4.2

Current behavior

After a bundle update (devise updated from 4.4.1 to 4.4.2), I now get the following failure when loading the server or running tests:

Devise.secret_key was not set. Please add the following to your Devise initializer: (RuntimeError)

  config.secret_key = 'ABC...'

Please ensure you restarted your application after installing Devise or setting the key.

Expected behavior

I didn't expect to change devise configuration for the patch level release. I'm using gem "devise", "~> 4.4.1" in gems.rb.

Setting this back to gem "devise", "4.4.1" fixes the issue for the moment.

I have the Rails.application.config.secret_key_base set in an initializer.

Some info from the docs:

Devise will use the secret_key_base as its secret_key
by default. You can change it below and use your own secret key.
config.secret_key = '<%= SecureRandom.hex(64) %>'

Let me know if you need more information about my setup, thanks!

[gssbzn]

I'm having the same issue (ruby 2.4.3 in my case)
I'm guessing this was introduced with https://github.com/plataformatec/devise/pull/4712
Forcing us to set the secret key by the use of credentials
I may try to debug it later

[remomueller]

Hmm, good catch, looks like a really rudimentary fix may look like this:

if app.respond_to?(:credentials) && app.credentials.secret_key_base.present?
  Devise.secret_key ||= app.credentials.secret_key_base
elsif app.respond_to?(:secrets)
  Devise.secret_key ||= app.secrets.secret_key_base
elsif app.config.respond_to?(:secret_key_base)
  Devise.secret_key ||= app.config.secret_key_base
end

Although, there's definitely a cleaner way of achieving the same result. (This change then leads to the rails5? bug reported here: #4806)

[tegon]

Looks like we haven't covered the case where a secret key base was already set 😞
I'll look into a fix for this.

[tegon]

@remomueller Just to make sure I understood the case correclty: you updated your app to Rails 5.2, right?
If so, from which version did you upgrade?
I'm asking this because you said you have Rails.application.config.secret_key_base in your initializer.

[remomueller]

@tegon, this recent update was from rails 5.1, however, the rails apps upgrades go back to rails 2 / rails 3.1. I haven't used secrets.yml.enc or the credentials that have been introduced as I've been using figaro to handle environment/application variables. (This was before both newer Rails conventions were introduced). Setting it this way still works in Rails 5.2, but I doubt that it's the preferred convention.

Edit: Looking back, it looks like that was used via config/initializers/secret_token.rb around the time of Rails 4.2.1.

[tegon]

@remomueller I see. I'm wondering whether your app hit the previous line before this version, which says Devise.secret_key ||= app.secrets.secret_key_base. Because even though this would be nil the app still responds to secrets. (and in this case, a similar error would happen?)
I guess we have to check if the app responds to the method and also if the value is present for all the conditions.

[remomueller]

I did a quick check, and it does go into the first part of the original if statement in v4.4.1 as it does respond to secrets. Also the variable: app.secrets.secret_key_base contains the key that I set (it's not blank).

if app.respond_to?(:secrets)
  # APP Goes here and has the key in app.secrets.secret_key_base
  Devise.secret_key ||= app.secrets.secret_key_base
elsif app.config.respond_to?(:secret_key_base)
  Devise.secret_key ||= app.config.secret_key_base
end

[tegon]

Oh, I see. Thanks for checking this.

[tegon]

@remomueller @gssbzn Can you help me test this? Use devise from the branch of #4810 and see if it's working?

[gssbzn]

@tegon Looks like it's working for me now, thanks for the quick response

[remomueller]

@tegon, just tried the let-fix-4807 branch and ran my tests, looks like everything is working as expected, thanks!

[tegon]

Fixed on version 4.4.3.

[cmitz]

Sorry to comment on a closed issue, but this still happens when using rails 5.1.6 with devise 4.4.3. Devise 4.4.1 still worked for me

Environment

• Ruby 2.5.1
• Rails 5.1.6
• Devise 4.4.3

And I'm getting the same error as remomueller.

[tegon]

@cmitz Can you run the following commands inside your rails console and paste their output here?
```ruby
Rails.application.credentials.secret_key_base

Rails.application.secrets.secret_key_base

Rails.application.config.secret_key_base

[cmitz]

Hi, thanks for the remarkably quick response. Here it is:

[1] pry(main)> Rails.application.credentials.secret_key_base
NoMethodError: undefined method `credentials' for #<Tomato::Application:0x00007fe212142de0>
from (pry):1:in `<main>'
[2] pry(main)> Rails.application.secrets.secret_key_base
"e3d3304b39dc13f2fbd50ce6bef4e3635cafd7bc81eb5421976665539b8279fad2c67b9336e2853d8b5104777b8fc9199bd20bf383a0beab291c8cd1cf6c2cb8"
[3] pry(main)>
[4] pry(main)> Rails.application.config.secret_key_base
nil

[tegon]

@cmitz That's odd, it seems like your application should have fallen on the second condition here: https://github.com/plataformatec/devise/blob/master/lib/devise/secret_key_finder.rb#L13 🤔
You are on the latest version, right? If so, can you add some debug statements to the Devise::SecretKeyFinder class to see in which condition your application is falling?

[cmitz]

I'm on 4.4.3. However, and I feel bad for not mentioning this earlier but I just realised this, it does not happen in development but only when deploying via docker-compose.

My setup breaks when I do the assets:precompile step. In that step, Devise is __completely right__ and the secret key is not available. The key is available, however, in the rails application as soon as it boots up.

I still think is really strange that this doesn't happen in Devise 4.4.1, but it might not be related to this specific issue🤔. Is Devise involved in the asset precompilation?

Edit: I see, this might work: #Heroku. Checking it out now.
Edit: This is not making sense. Nothing crucial should have changed for me between 4.4.1 and 4.4.2. Should I make a new issue?

FROM ruby:2.5.1-slim
RUN apt-get update -qq \
  && apt-get install -y \
  build-essential \
  git \
  libpq-dev \
  curl
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash - && \
  apt-get install -y \
  nodejs && \
  npm install -g yarn

RUN mkdir /app
WORKDIR /app

COPY Gemfile* /app/
RUN bundle install --without development test
COPY . /app

RUN printenv
RUN RAILS_ENV=production bundle exec rails assets:precompile

CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]

[tegon]

@cmitz Yeah, I think it's better to open another issue. I just saw now that you aren't on Rails 5.2 so this issue shouldn't have affected you.

[yordis]

@tegon Using config.secret_key = Rails.application.credentials.secret_key_base doesn't work when I push to Heroku.

Doing Rails.application.credentials.secret_key_base on rails c give me value so.

gem 'rails', '5.2.0'
ruby '2.5.1'

But because I am ploying to heroku there is not master.key so I need to setup the RAILS_MASTER_KEY key on the server with the same value of my master.key for be able to read the configuration.

[TravisSiebenhaar]

Just to add to what @yordis was saying. When you move your code to a server, you need to make sure that your config/credentials.yml.enc file can be decrypted. That means that somehow you’ll need to provide Rails with your master key, given that it is not checked into version control (which it shouldn't be by default and never really should be).

You have a couple of options to do this:

• Option 1: Place the config/master.key file in the server. You’ll normally want to symlink this file to a shared folder in the server filesystem. Again, do not version your config/master.key file.
• Option 2: create a RAILS_MASTER_KEY ENV variable. Rails will detect it and use it as your master key, e.g. in heroku: heroku config:set RAILS_MASTER_KEY=<your-master-key-here>.

Granted, this is done after you have gone through the necessary steps to set your Rails.application.credentials.secret_key_base. See Encrypted credentials on rails.

[yordis]

@Nappstir this is weird, I have another application which I am doing exactly the same but when I do bin/rails credentials:edit the error appears

/Users/ubi/.rvm/gems/ruby-2.5.1@prestige/gems/devise-4.4.3/lib/devise/rails/routes.rb:500:in `raise_no_secret_key': Devise.secret_key was not set. Please add the following to your Devise initializer: (RuntimeError)

  config.secret_key = '582580b13858af48f9c4466ed91678c125787ac98e0da8c070b96d7593b59e07283c9a577800183f9af89752389b0b36248b593e9de2ad4039973166d8a31452'

Please ensure you restarted your application after installing Devise or setting the key.

Like, why?!

I hardcoded the value and it let me pass. I closed it and there was no change on my credentials.yml.enc which means I was using the correct master.key because the encryption of the file didn't change so.

This is really really confusing that it is happening to me right now, also my Heroku app is failing even when I have the same master.key on the RAILS_MASTER_KEY config.

[bengm]

FWIW, adding a datapoint for whom it helps: We started getting this issue on a repo. Strange thing was that it started to happen at an odd time (not at the same time as a devise or rails version change, or circleCI setting change).

Info:

• rails 5.2.1
• devise 4.4.3
• circleCI version 2

The following devise config fixes didn't work:

• config.secret_key = Rails.application.secrets.secret_key_base
• config.secret_key = Rails.application.credentials.secret_key_base

Upgrading devise to 4.5.0 did work (with no explicit secret_key setting in Devise.setup as above).