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.rb
confond 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 à .gitignore
peu près comme vous n'ajouteriez pas non plus config/database.yml
au contrôle de code source.
En référençant le propre code de Heroku pour la configuration à config/database.yml
partir DATABASE_URL
de leur Buildpack pour Ruby , j'ai fini par forger leur dépôt et je l'ai modifié pour créer à config/secrets.yml
partir 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.rb
et 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.yml
variable d'environnement à partir de votre variable d'environnement dans le cadre du processus de construction dyno chaque fois que vous vous git push
rendrez à Heroku.
EDIT: La propre documentation de Heroku suggère de créer config/secrets.yml
pour 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.