Comment résoudre l'erreur «Manquant` secret_key_base` pour l'environnement de 'production' »(Rails 4.1)

J'ai créé une application Rails, en utilisant Rails 4.1, à partir de zéro et je suis confronté à un problème étrange que je ne parviens pas à résoudre.

Chaque fois que j'essaye de déployer mon application sur Heroku, j'obtiens une erreur 500:

Missing `secret_key_base` for 'production' environment, set this value in `config/secrets.yml`

Le secret.ymlfichier contient la configuration suivante:

secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

Sur Heroku, j'ai configuré la SECRET_KEY_BASEvariable d'environnement " " avec le résultat de la rake secretcommande. Si je lance heroku config, je peux voir la variable avec le nom et la valeur corrects.

Pourquoi est-ce que j'obtiens toujours cette erreur?

J'ai eu le même problème et je l'ai résolu en créant une variable d'environnement à charger à chaque fois que je me suis connecté au serveur de production, et j'ai créé un mini-guide des étapes pour le configurer:

J'utilisais Rails 4.1 avec Unicorn v4.8.2 et lorsque j'ai essayé de déployer mon application, cela n'a pas démarré correctement et dans le unicorn.logfichier, j'ai trouvé ce message d'erreur:

app error: Missing `secret_key_base` for 'production' environment, set this value in `config/secrets.yml` (RuntimeError)

Après quelques recherches, j'ai découvert que Rails 4.1 avait changé la façon de gérer le secret_key, donc si vous lisez le secrets.ymlfichier situé sur, exampleRailsProject/config/secrets.ymlvous trouverez quelque chose comme ceci:

# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

Cela signifie que Rails vous recommande d'utiliser une variable d'environnement pour le secret_key_basedans votre serveur de production. Afin de résoudre cette erreur, vous devez suivre ces étapes pour créer une variable d'environnement pour Linux (dans mon cas Ubuntu) sur votre serveur de production:

1. Dans le terminal de votre serveur de production, exécutez:

   $ RAILS_ENV=production rake secret

   Cela renvoie une grande chaîne avec des lettres et des chiffres. Copiez cela, que nous appellerons ce code GENERATED_CODE.

2. Connectez-vous à votre serveur

   • Si vous vous connectez en tant qu'utilisateur root, recherchez ce fichier et modifiez-le:

     $ vi /etc/profile

     Allez au bas du fichier en utilisant Shift+ G(«G» majuscule) dans vi.

     Écrivez votre variable d'environnement avec le GENERATED_CODE, en appuyant sur ipour insérer dans vi. Assurez-vous d'être dans une nouvelle ligne à la fin du fichier:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Enregistrez les modifications et fermez le fichier en utilisant Escet puis " :x" et Enterpour enregistrer et quitter dans vi.

   • Mais si vous vous connectez en tant qu'utilisateur normal, appelons-le " example_user" pour l'essentiel, vous devrez trouver l'un de ces autres fichiers:

     $ vi ~/.bash_profile
     $ vi ~/.bash_login
     $ vi ~/.profile

     Ces fichiers sont classés par ordre d'importance, ce qui signifie que si vous avez le premier fichier, vous n'avez pas besoin de modifier les autres. Si vous avez trouvé ces deux fichiers dans votre répertoire ~/.bash_profileet que ~/.profilevous n'aurez à écrire que dans le premier ~/.bash_profile, car Linux ne lira que celui-ci et l'autre sera ignoré.

     Ensuite, nous allons au bas du fichier en utilisant à nouveau Shift+ Get écrivons à nouveau la variable d'environnement avec notre GENERATED_CODEutilisation i, et assurez-vous d'ajouter une nouvelle ligne à la fin du fichier:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Après avoir écrit le code, enregistrez les modifications et fermez le fichier en utilisant à Escnouveau et " :x" et Enterpour enregistrer et quitter.

3. Vous pouvez vérifier que notre variable d'environnement est correctement définie sous Linux avec cette commande:

   $ printenv | grep SECRET_KEY_BASE

   ou avec:

   $ echo $SECRET_KEY_BASE

   Lorsque vous exécutez cette commande, si tout s'est bien passé, elle vous montrera le GENERATED_CODEprécédent. Enfin, une fois la configuration terminée, vous devriez pouvoir déployer sans problème votre application Rails avec Unicorn ou un autre outil.

Lorsque vous fermez votre shell et que vous vous connectez à nouveau au serveur de production, cette variable d'environnement est définie et prête à l'utiliser.

Et c'est tout! J'espère que ce mini-guide vous aidera à résoudre cette erreur.

Avertissement: Je ne suis pas un gourou de Linux ou de Rails, donc si vous trouvez quelque chose de mal ou une erreur, je serai heureux de le réparer.

Je vais supposer que vous n'avez pas archivé votre secrets.ymlcontrôle de code source (c'est-à-dire qu'il est dans le .gitignorefichier). Même si ce n'est pas votre situation, c'est ce que beaucoup d'autres personnes qui consultent cette question ont fait parce qu'elles ont leur code exposé sur Github et ne veulent pas que leur clé secrète flotte.

S'il n'est pas sous contrôle de code source, Heroku ne le sait pas. Donc Rails cherche Rails.application.secrets.secret_key_baseet il n'a pas été défini car Rails le définit en vérifiant le secrets.ymlfichier qui n'existe pas. La solution de contournement simple consiste à accéder à votre config/environments/production.rbfichier et à ajouter la ligne suivante:

Rails.application.configure do
    ...
    config.secret_key_base = ENV["SECRET_KEY_BASE"]
    ...
end

Cela indique à votre application de définir la clé secrète à l'aide de la variable d'environnement au lieu de la rechercher dans secrets.yml. Cela m'aurait fait gagner beaucoup de temps pour le savoir dès le départ.

Ajoutez config/secrets.ymlau contrôle de version et déployez à nouveau. Vous devrez peut-être supprimer une ligne de .gitignorepour pouvoir valider le fichier.

J'ai eu exactement le même problème et il s'est avéré que le passe-partout .gitignorecréé par Github pour mon application Rails était inclus config/secrets.yml.

Cela a fonctionné pour moi.

SSH dans votre serveur de production et cddans votre répertoire actuel, exécutez bundle exec rake secretou rake secret, vous obtiendrez une longue chaîne en sortie, copiez cette chaîne.

Maintenant, cours sudo nano /etc/environment.

Coller au bas du fichier

export SECRET_KEY_BASE=rake secret
ruby -e 'p ENV["SECRET_KEY_BASE"]'

Où rake secret trouve la chaîne que vous venez de copier, collez cette chaîne copiée à la place de rake secret.

Redémarrez le serveur et testez en exécutant echo $SECRET_KEY_BASE.

Bien que vous puissiez utiliser des initialiseurs comme les autres réponses, la méthode conventionnelle de Rails 4.1+ consiste à utiliser le config/secrets.yml. La raison pour laquelle l'équipe Rails d'introduire cela dépasse le cadre de cette réponse, mais le TL; DR est que cela secret_token.rbconfond la configuration et le code ainsi qu'un risque de sécurité puisque le jeton est archivé dans l'historique de contrôle de source et le seul système qui doit sachez que le jeton secret de production est l'infrastructure de production.

Vous devriez ajouter ce fichier à .gitignorepeu près comme vous n'ajouteriez pas non plus config/database.ymlau contrôle de code source.

En référençant le propre code de Heroku pour la configuration à config/database.ymlpartir DATABASE_URLde leur Buildpack pour Ruby , j'ai fini par forger leur dépôt et je l'ai modifié pour créer à config/secrets.ymlpartir deSECRETS_KEY_BASE la variable d'environnement.

Depuis que cette fonctionnalité a été introduite dans Rails 4.1, j'ai pensé qu'il était approprié de modifier ./lib/language_pack/rails41.rbet d'ajouter cette fonctionnalité.

Ce qui suit est l' extrait du buildpack modifié que j'ai créé dans mon entreprise:

class LanguagePack::Rails41 < LanguagePack::Rails4

  # ...

  def compile
    instrument "rails41.compile" do
      super
      allow_git do
        create_secrets_yml
      end
    end
  end

  # ...

  # writes ERB based secrets.yml for Rails 4.1+
  def create_secrets_yml
    instrument 'ruby.create_secrets_yml' do
      log("create_secrets_yml") do
        return unless File.directory?("config")
        topic("Writing config/secrets.yml to read from SECRET_KEY_BASE")
        File.open("config/secrets.yml", "w") do |file|
          file.puts <<-SECRETS_YML
<%
raise "No RACK_ENV or RAILS_ENV found" unless ENV["RAILS_ENV"] || ENV["RACK_ENV"]
%>

<%= ENV["RAILS_ENV"] || ENV["RACK_ENV"] %>:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
          SECRETS_YML
        end
      end
    end
  end

  # ...

end

Vous pouvez bien sûr étendre ce code pour ajouter d'autres secrets (par exemple des clés API tierces, etc.) à lire dans votre variable d'environnement:

...
<%= ENV["RAILS_ENV"] || ENV["RACK_ENV"] %>:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
  third_party_api_key: <%= ENV["THIRD_PARTY_API"] %>

De cette façon, vous pouvez accéder à ce secret de manière très standard:

Rails.application.secrets.third_party_api_key

Avant de redéployer votre application, assurez-vous de définir d'abord votre variable d'environnement:

Ajoutez ensuite votre buildpack modifié (ou vous êtes plus que bienvenu pour créer un lien vers le mien) à votre application Heroku (voir la documentation de Heroku ) et redéployez votre application.

Le buildpack créera automatiquement votre config/secrets.ymlvariable d'environnement à partir de votre variable d'environnement dans le cadre du processus de construction dyno chaque fois que vous vous git pushrendrez à Heroku.

EDIT: La propre documentation de Heroku suggère de créer config/secrets.ymlpour lire à partir de la variable d'environnement, mais cela implique que vous devez archiver ce fichier dans le contrôle de code source. Dans mon cas, cela ne fonctionne pas bien car j'ai des secrets codés en dur pour les environnements de développement et de test que je préfère ne pas enregistrer.

Vous pouvez exporter les clés secrètes en tant que variables d'environnement sur le ~/.bashrcou ~/.bash_profilede votre serveur:

export SECRET_KEY_BASE = "YOUR_SECRET_KEY"

Et puis, vous pouvez vous procurer votre .bashrcou .bash_profile:

source ~/.bashrc 
source ~/.bash_profile

Ne confiez jamais vos secrets.yml

Dans mon cas, le problème était que ce config/master.keyn'était pas dans le contrôle de version, et j'avais créé le projet sur un autre ordinateur.

Le .gitignore par défaut créé par Rails exclut ce fichier. Comme il est impossible de déployer sans avoir ce fichier, il doit être en contrôle de version, afin de pouvoir être déployé à partir de l'ordinateur de n'importe quel membre de l'équipe.

Solution: supprimez la config/master.keyligne de .gitignore, validez le fichier de l'ordinateur sur lequel le projet a été créé, et maintenant vous pouvez git pullsur l'autre ordinateur et déployer à partir de celui-ci.

Les gens disent de ne pas confier certains de ces fichiers au contrôle de version, sans offrir une solution alternative. Tant que vous ne travaillez pas sur un projet open source, je ne vois aucune raison de ne pas valider tout ce qui est nécessaire pour exécuter le projet, y compris les informations d'identification.

Pour rails6, j'étais confronté au même problème, car il me manquait les fichiers suivants, une fois que je les ai ajoutés, le problème est résolu:

1. config/master.key
2. config/credentials.yml.enc

Assurez-vous d'avoir ces fichiers. !!!

Ce que j'ai fait: Sur mon serveur de production, je crée un fichier de configuration (confthin.yml) pour Thin (je l'utilise) et j'ajoute les informations suivantes:

environment: production
user: www-data
group: www-data
SECRET_KEY_BASE: mysecretkeyproduction

Je lance ensuite l'application avec

thin start -C /whereeveristhefieonprod/configthin.yml

Travaillez comme un charme et alors pas besoin d'avoir la clé secrète sur le contrôle de version

J'espère que cela pourrait aider, mais je suis sûr que la même chose pourrait être faite avec Unicorn et d'autres.

J'ai un correctif que j'ai utilisé dans une application Rails 4.1 pour me permettre de continuer à utiliser le générateur de clés hérité (et donc la compatibilité de session en amont avec Rails 3), en permettant à secret_key_base d'être vide.

Rails::Application.class_eval do
  # the key_generator will then use ActiveSupport::LegacyKeyGenerator.new(config.secret_token)
  fail "I'm sorry, Dave, there's no :validate_secret_key_config!" unless instance_method(:validate_secret_key_config!)
  def validate_secret_key_config! #:nodoc:
    config.secret_token = secrets.secret_token
    if config.secret_token.blank?
      raise "Missing `secret_token` for '#{Rails.env}' environment, set this value in `config/secrets.yml`"
    end 
  end 
end

J'ai depuis reformaté le correctif et je l'ai soumis à Rails en tant que demande de tirage

J'ai créé le config/initializers/secret_key.rbfichier et je n'ai écrit que la ligne de code suivante:

Rails.application.config.secret_key_base = ENV["SECRET_KEY_BASE"]

Mais je pense que la solution postée par @Erik Trautman est plus élégante;)

Edit: Oh, et enfin j'ai trouvé ce conseil sur Heroku: https://devcenter.heroku.com/changelog-items/426 :)

Prendre plaisir!

cela fonctionne bien https://gist.github.com/pablosalgadom/4d75f30517edc6230a67 pour l'utilisateur root doit modifier

$ /etc/profile

mais si vous n'êtes pas root, mettez le code de génération dans ce qui suit

$ ~/.bash_profile

$ ~/.bash_login

$ ~/.profile

Sur Nginx / Passenger / Ruby (2.4) / Rails (5.1.1), rien d'autre ne fonctionnait sauf:

passenger_env_vardans /etc/nginx/sites-available/defaultle bloc serveur.

Source: https://www.phusionpassenger.com/library/config/nginx/reference/#passenger_env_var

La réponse Demi Magus a fonctionné pour moi jusqu'à Rails 5.

Sur Apache2 / Passenger / Ruby (2.4) / Rails (5.1.6), j'ai dû mettre

export SECRET_KEY_BASE=GENERATED_CODE

à partir de la réponse Demi Magus dans / etc / apache2 / envvars, car / etc / profile semble être ignoré.

Source: https://www.phusionpassenger.com/library/indepth/environment_variables.html#apache

J'ai eu le même problème après avoir utilisé le fichier .gitignore de https://github.com/github/gitignore/blob/master/Rails.gitignore

Tout s'est bien passé après avoir commenté les lignes suivantes dans le fichier .gitignore.

config/initializers/secret_token.rb
config/secrets.yml