Cómo resolver el error “Falta 'secret_key_base` para el entorno de' producción '” (Rails 4.1)

Creé una aplicación Rails, usando Rails 4.1, desde cero y me enfrento a un extraño problema que no puedo resolver.

Cada vez que intento implementar mi aplicación en Heroku me sale un error 500:

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

El secret.ymlarchivo contiene la siguiente configuración:

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

En Heroku configuré la " SECRET_KEY_BASE" variable de entorno con el resultado del rake secretcomando. Si inicio heroku config, puedo ver la variable con el nombre y el valor correctos.

¿Por qué sigo recibiendo este error?

Tuve el mismo problema y lo resolví creando una variable de entorno para cargar cada vez que iniciaba sesión en el servidor de producción, e hice una mini guía de los pasos para configurarlo:

Estaba usando Rails 4.1 con Unicorn v4.8.2 y cuando intenté implementar mi aplicación no se inició correctamente y en el unicorn.logarchivo encontré este mensaje de error:

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

Después de investigar un poco, descubrí que Rails 4.1 cambió la forma de administrar secret_keyel secrets.ymlarchivo , así que si lees el archivo ubicado en exampleRailsProject/config/secrets.ymleste, encontrarás algo como esto:

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

Esto significa que Rails le recomienda utilizar una variable de entorno para secret_key_baseen su servidor de producción. Para resolver este error, debe seguir estos pasos para crear una variable de entorno para Linux (en mi caso Ubuntu) en su servidor de producción:

1. En la terminal de su servidor de producción ejecute:

   $ RAILS_ENV=production rake secret

   Esto devuelve una cadena grande con letras y números. Copie eso, al que nos referiremos como código GENERATED_CODE.

2. Inicie sesión en su servidor

   • Si inicia sesión como usuario root, busque este archivo y edítelo:

     $ vi /etc/profile

     Vaya al final del archivo usando Shift+ G("G" mayúscula) en vi.

     Escriba su variable de entorno con GENERATED_CODE, presionando ipara insertar en vi. Asegúrese de estar en una nueva línea al final del archivo:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Guarde los cambios y cierre el archivo usando Escy luego " :x" y Enterpara guardar y salir en vi.

   • Pero si inicia sesión como usuario normal, llamémoslo " example_user" por esta esencia, necesitará encontrar uno de estos otros archivos:

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

     Estos archivos están en orden de importancia, lo que significa que si tiene el primer archivo, entonces no necesitaría editar los otros. Si encontró estos dos archivos en su directorio ~/.bash_profiley ~/.profilesolo tendrá que escribir en el primero ~/.bash_profile, porque Linux leerá solo este y el otro será ignorado.

     Luego vamos al final del archivo usando Shift+ Gnuevamente y escribimos la variable de entorno con nuestro GENERATED_CODEuso inuevamente, y asegúrese de agregar una nueva línea al final del archivo:

     $ export SECRET_KEY_BASE=GENERATED_CODE

     Después de escribir el código, guarde los cambios y cierre el archivo usando Esc" :x" nuevamente y Enterpara guardar y salir.

3. Puede verificar que nuestra variable de entorno esté configurada correctamente en Linux con este comando:

   $ printenv | grep SECRET_KEY_BASE

   o con:

   $ echo $SECRET_KEY_BASE

   Cuando ejecutas este comando, si todo salió bien, te mostrará el GENERATED_CODEde antes. Finalmente, con toda la configuración realizada, debería poder implementar sin problemas su aplicación Rails con Unicorn u otra herramienta.

Cuando cierre su shell e inicie sesión nuevamente en el servidor de producción, tendrá esta variable de entorno configurada y lista para usarla.

¡Y eso es! Espero que esta mini-guía te ayude a resolver este error.

Descargo de responsabilidad: no soy un gurú de Linux o Rails, por lo que si encuentra algo mal o algún error, me complacerá solucionarlo.

Asumiré que no ha secrets.ymlverificado su control de origen (es decir, está en el .gitignorearchivo). Incluso si esta no es su situación, es lo que muchas otras personas que vieron esta pregunta han hecho porque tienen su código expuesto en Github y no quieren que su clave secreta flote.

Si no está en el control de la fuente, Heroku no lo sabe. Así que Rails está buscando Rails.application.secrets.secret_key_basey no se ha configurado porque Rails lo configura al verificar el secrets.ymlarchivo que no existe. La solución simple es ir a su config/environments/production.rbarchivo y agregar la siguiente línea:

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

Esto le dice a su aplicación que establezca la clave secreta utilizando la variable de entorno en lugar de buscarla secrets.yml. Me habría ahorrado mucho tiempo saber esto por adelantado.

Agregar config/secrets.ymlal control de versiones e implementar nuevamente. Es posible que deba eliminar una línea .gitignorepara poder confirmar el archivo.

Tuve exactamente el mismo problema y resultó que .gitignoreincluía el repetitivo que Github creó para mi aplicación Rails config/secrets.yml.

Esto funcionó para mí.

SSH en su servidor de producción y cden su directorio actual, ejecute bundle exec rake secreto rake secret, obtendrá una cadena larga como salida, copie esa cadena.

Ahora corre sudo nano /etc/environment.

Pegar al final del archivo

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

¿Dónde rake secretestá la cadena que acaba de copiar? Pegue esa cadena copiada en lugar de rake secret.

Reinicie el servidor y pruebe ejecutando echo $SECRET_KEY_BASE.

Si bien puede usar inicializadores como las otras respuestas, la forma convencional de Rails 4.1+ es usar el config/secrets.yml. La razón para que el equipo de Rails presente esto está más allá del alcance de esta respuesta, pero el TL; DR es que secret_token.rbcombina la configuración y el código, además de ser un riesgo de seguridad, ya que el token se registra en el historial de control de fuente y el único sistema que necesita Conocer el token secreto de producción es la infraestructura de producción.

Debería agregar este archivo .gitignorecomo tampoco lo haría config/database.ymlcon el control de origen.

Haciendo referencia al propio código de Heroku para configurar config/database.ymldesde DATABASE_URLsu Buildpack para Ruby , terminé bifurcando su repositorio y lo modifiqué para crear config/secrets.ymldesde SECRETS_KEY_BASEla variable de entorno.

Dado que esta característica se introdujo en Rails 4.1, sentí que era apropiado editar ./lib/language_pack/rails41.rby agregar esta funcionalidad.

El siguiente es el fragmento del paquete de compilación modificado que creé en mi empresa:

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

Por supuesto, puede extender este código para agregar otros secretos (por ejemplo, claves API de terceros, etc.) para que se lean de su variable de entorno:

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

De esta manera, puede acceder a este secreto de una manera muy estándar:

Rails.application.secrets.third_party_api_key

Antes de volver a implementar su aplicación, asegúrese de configurar primero su variable de entorno:

A continuación, agregue su paquete de compilación modificado (o sea más que bienvenido a vincular el mío) a su aplicación Heroku (consulte la documentación de Heroku ) y vuelva a implementar su aplicación.

El paquete de compilación creará automáticamente su config/secrets.ymlvariable de entorno como parte del proceso de compilación de dinamómetro cada vez que vaya git pusha Heroku.

EDITAR: la propia documentación de Heroku sugiere crear config/secrets.ymlpara leer desde la variable de entorno, pero esto implica que debe verificar este archivo en el control de origen. En mi caso, esto no funciona bien ya que tengo secretos codificados para entornos de desarrollo y prueba que prefiero no registrar.

Puede exportar las claves secretas como variables de entorno en ~/.bashrco ~/.bash_profilede su servidor:

export SECRET_KEY_BASE = "YOUR_SECRET_KEY"

Y luego, puede obtener su .bashrco .bash_profile:

source ~/.bashrc 
source ~/.bash_profile

Nunca cometas tus secretos.yml

En mi caso, el problema era que config/master.keyno estaba en el control de versiones, y había creado el proyecto en una computadora diferente.

El .gitignore predeterminado que crea Rails excluye este archivo. Dado que es imposible implementar sin tener este archivo, debe estar en control de versiones, para poder implementar desde la computadora de cualquier miembro del equipo.

Solución: elimine la config/master.keylínea .gitignore, confirme el archivo de la computadora donde se creó el proyecto, y ahora puede git pullhacerlo en la otra computadora e implementarlo.

La gente dice que no debe comprometer algunos de estos archivos al control de versiones, sin ofrecer una solución alternativa. Mientras no esté trabajando en un proyecto de código abierto, no veo ninguna razón para no comprometer todo lo necesario para ejecutar el proyecto, incluidas las credenciales.

Para rails6, estaba enfrentando el mismo problema, ya que me faltaban los siguientes archivos, una vez que los agregué, el problema se resolvió:

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

Asegúrate de tener estos archivos. !!!

Lo que hice: en mi servidor de producción, creo un archivo de configuración (confthin.yml) para Thin (lo estoy usando) y agrego la siguiente información:

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

Luego inicio la aplicación con

thin start -C /whereeveristhefieonprod/configthin.yml

Trabaja como un encanto y luego no es necesario tener la clave secreta en el control de versiones

Espero que pueda ayudar, pero estoy seguro de que lo mismo podría hacerse con Unicorn y otros.

Tengo un parche que he usado en una aplicación Rails 4.1 para permitirme continuar usando el generador de claves heredado (y, por lo tanto, la compatibilidad de la sesión con Rails 3), permitiendo que secret_key_base esté en blanco.

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

Desde que reformateé el parche, lo envié a Rails como una solicitud de extracción

Creé el config/initializers/secret_key.rbarchivo y escribí solo la siguiente línea de código:

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

Pero creo que la solución publicada por @Erik Trautman es más elegante;)

Editar: Ah, y finalmente encontré este consejo sobre Heroku: https://devcenter.heroku.com/changelog-items/426 :)

¡Disfrutar!

esto funciona bien https://gist.github.com/pablosalgadom/4d75f30517edc6230a67 para el usuario root debe editar

$ /etc/profile

pero si usted no root debe poner el código de generación en el siguiente

$ ~/.bash_profile

$ ~/.bash_login

$ ~/.profile

En Nginx / Passenger / Ruby (2.4) / Rails (5.1.1) nada más funcionó excepto:

passenger_env_varen /etc/nginx/sites-available/defaultel bloque del servidor.

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

La respuesta de Demi Magus funcionó para mí hasta Rails 5.

En Apache2 / Passenger / Ruby (2.4) / Rails (5.1.6), tuve que poner

export SECRET_KEY_BASE=GENERATED_CODE

de la respuesta de Demi Magus en / etc / apache2 / envvars, la causa / etc / profile parece ignorarse.

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

Tuve el mismo problema después de usar el archivo .gitignore de https://github.com/github/gitignore/blob/master/Rails.gitignore

Todo salió bien después de comentar las siguientes líneas en el archivo .gitignore.

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