So beheben Sie den Fehler "Fehlende" secret_key_base "für" Produktionsumgebung "" (Rails 4.1)

Ich habe mit Rails 4.1 eine Rails-Anwendung von Grund auf neu erstellt und stehe vor einem seltsamen Problem, das ich nicht lösen kann.

Jedes Mal, wenn ich versuche, meine Anwendung auf Heroku bereitzustellen, wird die Fehlermeldung 500 angezeigt:

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

Die secret.ymlDatei enthält die folgende Konfiguration:

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

Auf Heroku habe ich die SECRET_KEY_BASEUmgebungsvariable " " mit dem Ergebnis des rake secretBefehls konfiguriert . Wenn ich starte heroku config, kann ich die Variable mit dem richtigen Namen und Wert sehen.

Warum erhalte ich diesen Fehler immer noch?

Ich hatte das gleiche Problem und löste es, indem ich eine Umgebungsvariable erstellte, die jedes Mal geladen werden sollte, wenn ich mich beim Produktionsserver anmeldete, und eine Kurzanleitung der Schritte zum Konfigurieren erstellte:

Ich habe Rails 4.1 mit Unicorn v4.8.2 verwendet und als ich versuchte, meine Anwendung bereitzustellen, wurde sie nicht richtig gestartet und in der unicorn.logDatei fand ich folgende Fehlermeldung:

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

Nach einigen Recherchen habe ich herausgefunden, dass Rails 4.1 die Art und Weise der Verwaltung geändert hat. secret_keyWenn Sie also die secrets.ymlDatei unter lesen, exampleRailsProject/config/secrets.ymlfinden Sie Folgendes:

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

Dies bedeutet, dass Rails Ihnen empfiehlt, eine Umgebungsvariable für die secret_key_basein Ihrem Produktionsserver zu verwenden. Um diesen Fehler zu beheben, sollten Sie die folgenden Schritte ausführen, um eine Umgebungsvariable für Linux (in meinem Fall Ubuntu) auf Ihrem Produktionsserver zu erstellen:

1. Führen Sie im Terminal Ihres Produktionsservers Folgendes aus:

   $ RAILS_ENV=production rake secret

   Dies gibt eine große Zeichenfolge mit Buchstaben und Zahlen zurück. Kopieren Sie das, als das wir diesen Code bezeichnen werden GENERATED_CODE.

2. Melden Sie sich bei Ihrem Server an

   • Wenn Sie sich als Root anmelden, suchen Sie diese Datei und bearbeiten Sie sie:

     $ vi /etc/profile

     Gehen Sie mit Shift+ G(Großbuchstabe "G") in vi zum Ende der Datei .

     Schreiben Sie Ihre Umgebungsvariable mit GENERATED_CODEund drücken Sie i, um in vi einzufügen. Stellen Sie sicher, dass Sie am Ende der Datei in einer neuen Zeile stehen:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Speichern Sie die Änderungen und schließen Sie die Datei mit Escund dann " :x" und Enterzum Speichern und Beenden in vi.

   • Wenn Sie sich jedoch als normaler Benutzer anmelden, nennen wir es " example_user" für diesen Kern. Sie müssen eine dieser anderen Dateien finden:

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

     Diese Dateien sind in der Reihenfolge ihrer Wichtigkeit angeordnet. Wenn Sie also die erste Datei haben, müssen Sie die anderen nicht bearbeiten. Wenn Sie diese beiden Dateien in Ihrem Verzeichnis gefunden haben ~/.bash_profileund ~/.profilenur die erste schreiben müssen, ~/.bash_profileliest Linux nur diese und die andere wird ignoriert.

     Dann gehen wir erneut mit Shift+ zum Ende der Datei Gund schreiben die Umgebungsvariable mit unserer erneuten GENERATED_CODEVerwendung ierneut. Fügen Sie am Ende der Datei eine neue Zeile hinzu:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Nachdem Sie den Code geschrieben haben, speichern Sie die Änderungen und schließen Sie die Datei mit Escerneut und " :x" und Enterzum Speichern und Beenden.

3. Mit diesem Befehl können Sie überprüfen, ob unsere Umgebungsvariable unter Linux richtig eingestellt ist:

   $ printenv | grep SECRET_KEY_BASE

   oder mit:

   $ echo $SECRET_KEY_BASE

   Wenn Sie diesen Befehl ausführen und alles in Ordnung ist, wird Ihnen das GENERATED_CODEvon zuvor angezeigt. Nach Abschluss der Konfiguration sollten Sie in der Lage sein, Ihre Rails-Anwendung problemlos mit Unicorn oder einem anderen Tool bereitzustellen.

Wenn Sie Ihre Shell schließen und sich erneut beim Produktionsserver anmelden, ist diese Umgebungsvariable festgelegt und kann verwendet werden.

Und das ist es! Ich hoffe, dieser Mini-Guide hilft Ihnen, diesen Fehler zu beheben.

Haftungsausschluss: Ich bin kein Linux- oder Rails-Guru. Wenn Sie also etwas falsch finden oder einen Fehler finden, kann ich ihn gerne beheben.

Ich gehe davon aus, dass Sie Ihre secrets.ymlQuellcodeverwaltung nicht eingecheckt haben (dh sie befindet sich in der .gitignoreDatei). Auch wenn dies nicht Ihre Situation ist, haben es viele andere Personen getan, die diese Frage sehen, weil sie ihren Code auf Github verfügbar gemacht haben und nicht möchten, dass ihr geheimer Schlüssel herumschwebt.

Wenn es nicht in der Quellcodeverwaltung ist, weiß Heroku nichts davon. Rails sucht also Rails.application.secrets.secret_key_baseund es wurde nicht festgelegt, da Rails es durch Überprüfen der secrets.ymlDatei festlegt, die nicht vorhanden ist. Die einfache Problemumgehung besteht darin, in Ihre config/environments/production.rbDatei zu gehen und die folgende Zeile hinzuzufügen:

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

Dadurch wird Ihre Anwendung angewiesen, den geheimen Schlüssel mithilfe der Umgebungsvariablen festzulegen, anstatt ihn zu suchen secrets.yml. Es hätte mir viel Zeit gespart, dies von vornherein zu wissen.

In config/secrets.ymlder Versionskontrolle und bereitstellen wieder. Möglicherweise müssen Sie eine Zeile aus entfernen, .gitignoredamit Sie die Datei festschreiben können.

Ich hatte genau das gleiche Problem und es stellte sich heraus, dass das .gitignorefür meine Rails-Anwendung erstellte Boilerplate Github enthalten war config/secrets.yml.

Das hat bei mir funktioniert.

cdFühren Sie SSH in Ihren Produktionsserver und in Ihr aktuelles Verzeichnis aus, führen Sie es aus bundle exec rake secretoder rake secretkopieren Sie diese Zeichenfolge, wenn Sie eine lange Zeichenfolge als Ausgabe erhalten.

Jetzt renn sudo nano /etc/environment.

Fügen Sie am Ende der Datei ein

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

Wo rake secretsich die gerade kopierte Zeichenfolge befindet, fügen Sie diese kopierte Zeichenfolge anstelle von ein rake secret.

Starten Sie den Server neu und testen Sie ihn durch Ausführen echo $SECRET_KEY_BASE.

Während Sie Initialisierer wie die anderen Antworten verwenden können, besteht die herkömmliche Methode von Rails 4.1+ darin, die zu verwenden config/secrets.yml. Der Grund für das Rails-Team, dies einzuführen, liegt außerhalb des Rahmens dieser Antwort, aber der TL; DR besteht darin, dass secret_token.rbKonfiguration und Code zusammengeführt werden und ein Sicherheitsrisiko darstellt, da das Token in den Versionsverwaltungsverlauf eingecheckt wird und das einzige System ist, das dies benötigt Ich weiß, dass das Produktionsgeheimnis die Produktionsinfrastruktur ist.

Sie sollten diese Datei .gitignoreso hinzufügen config/database.yml, als würden Sie sie auch nicht zur Quellcodeverwaltung hinzufügen .

Referenzierung Heroku eigenen Code für die Einrichtung config/database.ymlvon DATABASE_URLihrer Buildpack für Ruby , landete ich ihre Repo - gabeln und modifiziert es schaffen config/secrets.ymlvon SECRETS_KEY_BASEUmgebungsvariablen.

Da diese Funktion in Rails 4.1 eingeführt wurde, hielt ich es für angemessen, ./lib/language_pack/rails41.rbdiese Funktionalität zu bearbeiten und hinzuzufügen.

Das Folgende ist der Ausschnitt aus dem modifizierten Buildpack, das ich in meiner Firma erstellt habe:

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

Sie können diesen Code natürlich erweitern, um andere Geheimnisse (z. B. API-Schlüssel von Drittanbietern usw.) hinzuzufügen, die aus Ihrer Umgebungsvariablen ausgelesen werden sollen:

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

Auf diese Weise können Sie auf ganz normale Weise auf dieses Geheimnis zugreifen:

Rails.application.secrets.third_party_api_key

Stellen Sie vor dem erneuten Bereitstellen Ihrer App sicher, dass Sie zuerst Ihre Umgebungsvariable festlegen:

Fügen Sie dann Ihr modifiziertes Buildpack (oder Sie können gerne einen Link zu meinem erstellen) zu Ihrer Heroku-App hinzu (siehe Herokus Dokumentation ) und stellen Sie Ihre App erneut bereit.

Das Buildpack erstellt Ihre config/secrets.ymlVariable automatisch als Teil des Dyno- Erstellungsprozesses aus Ihrer Umgebungsvariablen, wenn Sie git pushzu Heroku gehen.

BEARBEITEN: Herokus eigene Dokumentation schlägt vor, config/secrets.ymlaus der Umgebungsvariablen zu lesen, dies bedeutet jedoch, dass Sie diese Datei in die Quellcodeverwaltung einchecken sollten. In meinem Fall funktioniert dies nicht gut, da ich Geheimnisse für Entwicklungs- und Testumgebungen fest codiert habe, die ich lieber nicht einchecken möchte.

Sie können die geheimen Schlüssel als Umgebungsvariablen auf dem ~/.bashrcoder ~/.bash_profileIhres Servers exportieren :

export SECRET_KEY_BASE = "YOUR_SECRET_KEY"

Und dann können Sie Ihre .bashrcoder .bash_profile:

source ~/.bashrc 
source ~/.bash_profile

Verpflichte niemals deine Geheimnisse

In meinem Fall bestand das Problem darin, dass die config/master.keyVersionskontrolle nicht durchgeführt wurde und ich das Projekt auf einem anderen Computer erstellt hatte.

Der von Rails erstellte Standard-Gitignore schließt diese Datei aus. Da die Bereitstellung ohne diese Datei nicht möglich ist, muss sie in der Versionskontrolle sein, damit sie von jedem Computer eines Teammitglieds aus bereitgestellt werden kann.

Lösung: Entfernen Sie die config/master.keyZeile von .gitignore, schreiben Sie die Datei von dem Computer fest, auf dem das Projekt erstellt wurde, und jetzt können Sie sie git pullauf dem anderen Computer bereitstellen und von dort aus bereitstellen.

Die Leute sagen, dass einige dieser Dateien nicht der Versionskontrolle übergeben werden sollen, ohne eine alternative Lösung anzubieten. Solange Sie nicht an einem Open Source-Projekt arbeiten, sehe ich keinen Grund, nicht alles festzuschreiben, was zum Ausführen des Projekts erforderlich ist, einschließlich der Anmeldeinformationen.

Bei Rails6 hatte ich das gleiche Problem, da mir folgende Dateien fehlten. Nachdem ich sie hinzugefügt hatte, wurde das Problem behoben:

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

Stellen Sie sicher, dass Sie diese Dateien haben. !!!

Was ich getan habe: Auf meinem Produktionsserver erstelle ich eine Konfigurationsdatei (confthin.yml) für Thin (ich verwende sie) und füge die folgenden Informationen hinzu:

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

Ich starte dann die App mit

thin start -C /whereeveristhefieonprod/configthin.yml

Arbeiten Sie wie ein Zauber und brauchen Sie dann nicht den geheimen Schlüssel für die Versionskontrolle

Ich hoffe, es könnte helfen, aber ich bin sicher, dass das Gleiche mit Unicorn und anderen gemacht werden könnte.

Ich habe einen Patch, den ich in einer Rails 4.1-App verwendet habe, damit ich den Legacy-Schlüsselgenerator (und damit die Abwärtssitzungskompatibilität mit Rails 3) weiterhin verwenden kann, indem die secret_key_base leer bleibt.

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

Ich habe den Patch seitdem neu formatiert und als Pull-Request an Rails gesendet

Ich habe eine config/initializers/secret_key.rbDatei erstellt und nur die folgende Codezeile geschrieben:

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

Aber ich denke, dass die von @Erik Trautman veröffentlichte Lösung eleganter ist;)

Edit: Oh, und schließlich habe ich diesen Rat auf Heroku gefunden: https://devcenter.heroku.com/changelog-items/426 :)

Genießen!

Dies funktioniert gut https://gist.github.com/pablosalgadom/4d75f30517edc6230a67 für Root-Benutzer sollte bearbeiten

$ /etc/profile

Wenn Sie jedoch kein Root sind, sollten Sie den generierten Code wie folgt eingeben

$ ~/.bash_profile

$ ~/.bash_login

$ ~/.profile

Auf Nginx / Passenger / Ruby (2.4) / Rails (5.1.1) funktionierte nichts anderes als:

passenger_env_varin /etc/nginx/sites-available/defaultim Serverblock.

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

Demi Magus Antwort funktionierte für mich bis Rails 5.

Auf Apache2 / Passenger / Ruby (2.4) / Rails (5.1.6) musste ich setzen

export SECRET_KEY_BASE=GENERATED_CODE

von Demi Magus Antwort in / etc / apache2 / envvars, Ursache / etc / Profil scheint ignoriert zu werden.

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

Ich hatte das gleiche Problem, nachdem ich die .gitignore-Datei von https://github.com/github/gitignore/blob/master/Rails.gitignore verwendet hatte

Alles hat gut geklappt, nachdem ich die folgenden Zeilen in der .gitignore-Datei kommentiert habe.

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