Как решить ошибку "отсутствует" база секретных ключей " для "производственной" среды "(Rails 4.1)

Я собираюсь предположить, что у вас нет своего secrets.yml проверено в системе управления версиями (т. е. это в ). Даже если это не ваша ситуация, это то, что многие другие люди, просматривающие этот вопрос, сделали, потому что у них есть свой код, открытый на Github, и они не хотят, чтобы их секретный ключ плавал вокруг.

если это не в системе управления версиями, Heroku не знает об этом. Так что рельсы ищет Rails.application.secrets.secret_key_base и он не был установлен, потому что Rails устанавливает его, проверяя secrets.yml файл, который не существует. Простой обходной путь заключается в том, чтобы войти в ваш config/environments/production.rb файл и добавить следующую строку:

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

это говорит ваше приложение, чтобы установить секретный ключ с помощью переменной среды, а не искать его в secrets.yml. Это сэкономило бы мне много времени, чтобы узнать это заранее.

добавить config/secrets.yml для управления версиями и развертывания снова. Возможно, вам придется удалить строку из .gitignore, Так что вы можете совершить файла.

у меня была такая же проблема, и просто оказалось, что шаблон .gitignore Github создан для моего приложения Rails включены config/secrets.yml.

это работает для меня.

SSH в ваш рабочий сервер и cd в текущем каталоге, выполните команду bundle exec rake secret или rake secret, вы получите длинную строку в качестве выходного, скопируйте эту строку.

теперь бегите sudo nano /etc/environment.

вставить в конец файла

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

здесь rake secret - это строка, которую вы просто скопировали, вставьте скопированные строки rake secret.

перезагрузите сервер и протестируйте его, запустив echo $SECRET_KEY_BASE.

в то время как вы можете использовать инициализаторы, как и другие ответы, обычные рельсы 4.1+ способ заключается в использовании config/secrets.yml. Причина, по которой команда Rails представила это, выходит за рамки этого ответа, но TL;DR-это secret_token.rb объединяет конфигурацию и код, а также представляет угрозу безопасности, поскольку маркер проверяется в истории управления версиями, и единственная система, которая должна знать секретный маркер производства, - это производственная инфраструктура.

вы должны добавить это файл в .gitignore так же, как вы бы не добавили config/database.yml источник контроля или.

ссылка на собственный код Heroku для настройки config/database.yml С DATABASE_URL в своем Buildpack для Ruby, я закончил разветвляя их РЕПО и изменил его, чтобы создать config/secrets.yml С SECRETS_KEY_BASE переменные среды.

так как эта функция была введена в Rails 4.1, я чувствовал, что это было уместно редактировать ./lib/language_pack/rails41.rb и добавить эту функцию.

в ниже приводится фрагмент из модифицированного пакета buildpack, который я создал в своей компании:

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

вы можете, конечно, расширить этот код, чтобы добавить другие секреты (например, сторонние ключи API и т. д.) для считывания переменной среды:

...
<%= 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

перед повторным развертыванием приложения сначала установите переменную среды:

затем добавьте изменен buildpack-пакет (или вы более чем приветствуется, чтобы связаться с моей), чтобы ваше приложение в Heroku (см. в Heroku документация) и повторно развернуть приложение.

buildpack автоматически создаст ваш config/secrets.yml из переменной среды как часть процесса сборки dyno каждый раз, когда вы git push в Heroku.

изменить: собственные в Heroku документация предполагает создание config/secrets.yml для чтения из переменной среды, но это означает, что вы должны проверить этот файл в систему управления версиями. В моем случае это не работает хорошо, так как у меня есть жестко закодированные секреты для разработки и тестирования сред, которые я бы предпочел не проверять.

вы можете экспортировать секретные ключи в качестве переменных среды на ~/.bashrc или ~/.bash_profile сервер:

export SECRET_KEY_BASE = "YOUR_SECRET_KEY"

и потом, вы можете источник .bashrc или .bash_profile:

source ~/.bashrc 
source ~/.bash_profile

никогда не раскрывайте свои секреты.в формате YML

что я сделал : На моем рабочем сервере я создаю конфигурационный файл (confthin.yml) для Thin (я использую его) и добавьте следующую информацию:

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

затем я запускаю приложение с

thin start -C /whereeveristhefieonprod/configthin.yml

работать как шарм, а затем не нужно иметь секретный ключ на контроль версий

надеюсь, что это может помочь, но я уверен, что то же самое можно сделать с единорогом и другими.

У меня есть патч, который я использовал в приложении Rails 4.1, чтобы позволить мне продолжать использовать генератор устаревших ключей (и, следовательно, обратную совместимость сеанса с Rails 3), позволяя secret_key_base быть пустым.

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

С тех пор я переформатировал патч отправил его в Rails в качестве запроса на вытягивание

Я создал config/initializers/secret_key.rb файл и я написал только следующую строку кода:

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

но я думаю, что решение опубликовано @Erik Trautman более элегантно ;)

изменить: Ну, и, наконец, я нашел этот совет на Heroku: https://devcenter.heroku.com/changelog-items/426 :)

наслаждайтесь!

это работает хорошо https://gist.github.com/pablosalgadom/4d75f30517edc6230a67 для пользователя root необходимо отредактировать

$ /etc/profile

но если вы не корень должен поставить код генерации в следующем

$ ~/.bash_profile

$ ~/.bash_login

$ ~/.profile

на Nginx / Passenger / Ruby (2.4) / Rails (5.1.1) больше ничего не работало, кроме:

passenger_env_var на /etc/nginx/sites-available/default в блоке сервер.

Источник: https://www.phusionpassenger.com/library/config/nginx/reference/#passenger_env_var

ответ Деми мага работал для меня до Rails 5.

на Apache2 / Passenger / Ruby (2.4) / Rails (5.1.6), я должен был поставить

export SECRET_KEY_BASE=GENERATED_CODE

из ответа Demi Magus в /etc/apache2 /envvars, причина/etc / профиль, кажется, игнорируется.

Источник: https://www.phusionpassenger.com/library/indepth/environment_variables.html#apache

У меня была такая же проблема после того, как я использовал .gitignore файл из https://github.com/github/gitignore/blob/master/Rails.gitignore

все работало нормально, после того как я прокомментировал следующие строки .файла.gitignore

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