Jak rozwiązać błąd "Brak' tajnej bazy kluczy 'dla środowiska' produkcyjnego '" (Rails 4.1)

Zakładam, że nie masz swojego secrets.yml sprawdzonego w kontroli źródła (tj. jest w pliku .gitignore). Nawet jeśli nie jest to twoja sytuacja, wiele innych osób oglądających to pytanie zrobiło tak, ponieważ mają swój kod ujawniony na Githubie i nie chcą, aby ich tajny klucz krążył wokół.

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

Mówi To aplikacji, aby ustawiła tajny klucz przy użyciu zmiennej środowiskowej zamiast szukać go w secrets.yml. Zaoszczędziłoby mi to dużo czasu, gdybym wiedział o tym z góry.

Dodać config/secrets.yml do kontroli wersji i wdrożyć ponownie. Może być konieczne usunięcie linii z .gitignore, aby można było zatwierdzić plik.

Miałem dokładnie ten sam problem i okazało się, że boilerplate .gitignore Github stworzony dla mojej aplikacji Rails zawiera config/secrets.yml.

To mi pomogło.

SSH do serwera produkcyjnego i cd do bieżącego katalogu, uruchom bundle exec rake secret lub rake secret, otrzymasz długi łańcuch jako wyjście, skopiuj ten łańcuch.

A teraz uciekaj sudo nano /etc/environment.

Wklej na dole pliku

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

Gdzie rake secret jest właśnie skopiowanym łańcuchem, wklej ten skopiowany łańcuch w miejsce rake secret.

Uruchom ponownie serwer i przetestuj przez uruchomienie echo $SECRET_KEY_BASE.

Podczas gdy możesz używać inicjalizatorów, tak jak inne odpowiedzi, konwencjonalnym sposobem Rails 4.1+ jest użycie config/secrets.yml. Powodem, dla którego zespół Rails wprowadził To rozwiązanie jest poza zakresem tej odpowiedzi, ale TL; DR jest to, że secret_token.rb łączy konfigurację i kod, a także stanowi zagrożenie bezpieczeństwa, ponieważ token jest sprawdzany w historii kontroli źródeł i jedynym systemem, który musi znać tajny token produkcji, jest Infrastruktura produkcyjna.

Powinieneś dodać ten plik do .gitignore podobnie jak nie dodałbyś config/database.yml do kontroli źródła.

Nawiązując do własnego kodu Heroku do konfiguracji config/database.yml z DATABASE_URLw ich Buildpack for Ruby , skończyłem rozwidlając ich repo i zmodyfikowałem go, aby utworzyć config/secrets.yml ze zmiennej środowiskowej SECRETS_KEY_BASE.

Ponieważ ta funkcja została wprowadzona w Rails 4.1, uznałem za stosowne edytować ./lib/language_pack/rails41.rb i dodać tę funkcjonalność.

Poniżej znajduje się fragment ze zmodyfikowanego buildpacka I stworzony w mojej firmie:

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

Możesz oczywiście rozszerzyć ten kod, aby dodać inne tajemnice (np. klucze API innych firm itp.) do odczytu ze zmiennej środowiskowej:

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

Rails.application.secrets.third_party_api_key

Przed ponownym uruchomieniem aplikacji należy najpierw ustawić zmienną środowiskową:

Następnie dodaj swój zmodyfikowany buildpack (lub jesteś bardziej niż mile widziany, aby link do mojego) do swojej aplikacji Heroku (zobacz Heroku dokumentacja) i przesuń swoją aplikację.

Buildpack automatycznie utworzy config/secrets.yml ze zmiennej środowiskowej jako część procesu budowania dyno za każdym razem, gdy git push trafisz do Heroku.

EDIT: własna dokumentacja Heroku sugeruje utworzenie config/secrets.yml do odczytu ze zmiennej środowiskowej, ale oznacza to, że powinieneś sprawdzić ten plik w kontroli źródła. W moim przypadku nie działa to dobrze, ponieważ mam zakodowane sekrety rozwoju i testowania środowiska, których wolałbym nie sprawdzać.

W przypadku rails6 miałem ten sam problem, ponieważ brakowało mi następujących plików, po dodaniu ich problem rozwiązany:

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

Upewnij się, że masz te pliki.!!!

Możesz wyeksportować tajne klucze do zmiennych środowiskowych na ~/.bashrc lub ~/.bash_profile twojego serwera:

export SECRET_KEY_BASE = "YOUR_SECRET_KEY"

A następnie możesz podać swoje .bashrc lub .bash_profile:

source ~/.bashrc 
source ~/.bash_profile

Nigdy nie zdradzaj swoich sekretów.yml

W moim przypadku problem polegał na tym, że config/master.key nie było w kontroli wersji, a ja stworzyłem projekt na innym komputerze.

Domyślne .gitignore, który tworzy Rails, wyklucza ten plik. Ponieważ nie można go wdrożyć bez posiadania tego pliku, musi on być pod kontrolą wersji, aby móc go wdrożyć z komputera dowolnego członka zespołu.

Rozwiązanie: usuń linię config/master.key z .gitignore, Zatwierdź Plik z komputera, na którym został utworzony projekt, a teraz możesz git pull na drugim komputerze i wdrożyć z niego.

Ludzie mówią, aby nie przenosić niektórych z tych plików do kontroli wersji, bez oferowania alternatywnego rozwiązania. Dopóki nie pracujesz nad projektem open source, nie widzę powodu, aby nie zatwierdzać wszystkiego, co jest wymagane do uruchomienia projektu, w tym poświadczeń.

What I did : Na moim serwerze produkcyjnym tworzę plik config (confthin.yml) dla Thin (używam go) i dodaj następującą informację:

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

Następnie uruchamiam aplikację z

thin start -C /whereeveristhefieonprod/configthin.yml

Działa jak czar, a następnie nie trzeba mieć tajnego klucza w kontroli wersji

Mam łatkę, której użyłem w aplikacji Rails 4.1, aby pozwolić mi kontynuować korzystanie z generatora kluczy starszych (a tym samym kompatybilność sesji wstecznej z Rails 3), pozwalając secret_key_base być puste.

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

Od tego czasu sformatowałem łatkę wysłałem ją do Rails jako Pull Request

Utworzyłem config/initializers/secret_key.rb plik i napisałem tylko następującą linijkę kodu:

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

Ale myślę, że rozwiązanie dodane przez @ Erik Trautman jest bardziej eleganckie;)

Edytuj: No i w końcu znalazłem taką radę na Heroku: https://devcenter.heroku.com/changelog-items/426 :)

This is works good https://gist.github.com/pablosalgadom/4d75f30517edc6230a67 dla użytkownika root należy edytować

$ /etc/profile

Ale jeśli nie root należy umieścić kod generujący w następujący

$ ~/.bash_profile

$ ~/.bash_login

$ ~/.profile

Na Nginx / Passenger / Ruby (2.4)/Rails (5.1.1) nic innego nie działało poza:

passenger_env_var in /etc/nginx/sites-available/default in the server block.

Źródło: https://www.phusionpassenger.com/library/config/nginx/reference/#passenger_env_var

Demi Magus odpowiedź działała dla mnie do Rails 5.

export SECRET_KEY_BASE=GENERATED_CODE

Źródło: https://www.phusionpassenger.com/library/indepth/environment_variables.html#apache

Miałem ten sam problem po użyciu .plik gitignore z https://github.com/github/gitignore/blob/master/Rails.gitignore

Wszystko poszło dobrze po tym, jak skomentowałem następujące linijki w .plik gitignore.

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