ruby-on-rails ruby ruby-on-rails-4 devise secret-key

ruby on rails - ¿Cuál es el uso de secret_key_base en rieles 4



ruby-on-rails ruby-on-rails-4 (2)

secret_key_base se usa para encriptar y firmar sesión

para enviar de forma segura una sesión de ida y vuelta en las cookies

En Rails 4 ,

  1. si su aplicación se llama Hello , y
  2. estableces session[''a''] = ''b'' ,

su cookie se verá algo como esto:

_Hello_session=BAh7B0kiD3%3D%3D--dc40a55cd52fe32bb3b84ae0608956dfb5824689

que se traduce en:

_Hello_session=<encrypted a=b>--<digital signature>

Las cookies se configuran por el servidor y se guardan en el lado del cliente, con el reenvío del navegador se establecen cookies en el servidor cada vez que solicitamos una página.

Para evitar que las personas malvadas comprendan a=b cadena a a=b , está encriptada .
Para evitar que las personas malvadas manipulen las cookies, se utiliza la firma digital .

En ambos casos se usa el valor de secret_key_base (para cifrar / descifrar a = b y para validar la firma digital).

Soy nuevo en Rails 4 y no entiendo el uso de secret_key_base en config/secrets.yml en Rails 4. ¿Puedes explicar este concepto?

Además, cuando estoy trabajando en el entorno de producción, se me solicita que configure secret_key con devise.rb , config.secret_key y secret_key_base . Sin embargo, puedo generar un nuevo secreto usando el comando rake secret .

¿Cuál es la diferencia entre entornos de desarrollo y producción?

¿Cómo se corresponde con la secret_key recién generada cuando la agrego con secret_key_base cada vez que genero?

¿Cómo se asegura la aplicación con otros servidores?


El contenido del archivo secret_token.rb incluye una cadena larga aleatoria que se utiliza para verificar la integridad de las cookies firmadas (como las sesiones de usuario cuando las personas secret_token.rb sesión en su aplicación web).

Documentation dice:

Utilice su secret_key_base existente desde el inicializador secret_token.rb para establecer la variable de entorno SECRET_KEY_BASE para los usuarios que ejecuten la aplicación Rails en modo de producción. Alternativamente, puede simplemente copiar la secret_key_base existente desde el inicializador secret_token.rb a secrets.yml en la sección de producción, reemplazando <%= ENV["SECRET_KEY_BASE"] %> .

Dado que es un archivo importante, y no se puede poner en .gitignore, se considera una buena práctica usar la variable env para almacenar el valor de secret_key_base :

crea .env archivo .env o .powenv y .powenv como:

export SECRET_TOKEN="9489b3eee4eccf317ed77407553e8adc97baca7c74dc7ee33cd93e4c8b69477eea66eaedeb18af0be2679887c7c69c0a28c0fded0a71ea472a8c4laalal19cb"

Y luego en config/initializers/secret_token.rb

YourAppName::Application.config.secret_key_base = if Rails.env.development? or Rails.env.test? # generate simple key for test and development environments (''a'' * 30) # should be at least 30 chars long else ENV[''SECRET_TOKEN''] end

Este artículo es (un poco viejo y) largo, pero realmente lleno de información útil sobre el tema.

ACTUALIZACIÓN 04.05.15

A partir de Rails 4.2 ya no secret_token.rb archivo secret_token.rb . Por nueva convención, hay un archivo config/secrets.yml destinado a almacenar secretos de la aplicación.

Lea sobre cómo actualizar una aplicación existente a 4.2.x de acuerdo con las innovaciones.

Técnicamente, el objetivo de secrect_key_base es ser la entrada secreta para el método key_generator la aplicación (ver Rails.application.key_generator ).

El key_generator la aplicación, y por lo tanto secret_key_base , son utilizados por tres características principales dentro del framework de Rails:

  • Derivación de claves para cookies encriptadas a las que se puede acceder a través de cookies.encrypted .
  • Derivar la clave para las cookies firmadas HMAC a las que se puede acceder mediante cookies.signed .
  • Derivación de claves para todas las instancias de message_verifier denominadas de la aplicación.

Consulte más sobre cada uno de los tres en el artículo de @michaeljcoyne .