Nunca codifique información confidencial (credenciales de cuenta, contraseñas, etc.) . En su lugar, cree un archivo para almacenar esa información como variables de entorno (pares clave / valor) y excluya ese archivo de su sistema de administración de código fuente. Por ejemplo, en términos de Git (sistema de administración de código fuente), excluya ese archivo agregándolo a. gitignore :
-bash> echo '/config/app_environment_variables.rb' >> .gitignore
/config/app_environment_variables.rb
ENV['HTTP_USER'] = 'devuser'
ENV['HTTP_PASS'] = 'devpass'
Además, agregue las siguientes líneas /config/environment.rb
entre la require
línea y la Application.initialize
línea:
app_environment_variables = File.join(Rails.root, 'config', 'app_environment_variables.rb')
load(app_environment_variables) if File.exists?(app_environment_variables)
¡Eso es!
Como dice el comentario anterior, al hacer esto, estará cargando sus variables de entorno antes environments/*.rb
, lo que significa que podrá hacer referencia a sus variables dentro de esos archivos (por ejemplo environments/production.rb
). Esta es una gran ventaja sobre poner su archivo de variables de entorno dentro /config/initializers/
.
En el interior app_environment_variables.rb
no es necesario distinguir los entornos en cuanto a desarrollo o producción porque nunca enviará este archivo a su sistema de gestión de código fuente, por lo que es para el contexto de desarrollo de forma predeterminada. Pero si necesita establecer algo especial para el entorno de prueba (o para ocasiones en las que prueba el modo de producción localmente ), simplemente agregue un bloque condicional debajo de todas las demás variables:
if Rails.env.test?
ENV['HTTP_USER'] = 'testuser'
ENV['HTTP_PASS'] = 'testpass'
end
if Rails.env.production?
ENV['HTTP_USER'] = 'produser'
ENV['HTTP_PASS'] = 'prodpass'
end
Siempre que actualice app_environment_variables.rb
, reinicie el servidor de aplicaciones. Suponiendo que está utilizando Apache / Passenger o rails server
:
-bash> touch tmp/restart.txt
En su código, consulte las variables de entorno de la siguiente manera:
def authenticate
authenticate_or_request_with_http_basic do |username, password|
username == ENV['HTTP_USER'] && password == ENV['HTTP_PASS']
end
end
Tenga en cuenta que dentro app_environment_variables.rb
debe especificar booleanos y números como cadenas (por ejemplo, ENV['SEND_MAIL'] = 'false'
no solo false
, y ENV['TIMEOUT'] = '30'
no solo 30
), de lo contrario obtendrá los errores can't convert false into String
y can't convert Fixnum into String
, respectivamente.
Almacenar y compartir información confidencial
El nudo final a atar es: ¿cómo compartir esta información sensible con sus clientes y / o socios? Con el fin de la continuidad del negocio (es decir, cuando te golpea una estrella fugaz, ¿cómo reanudarán tus clientes y / o socios las operaciones completas del sitio?), Tus clientes y / o socios deben conocer todas las credenciales requeridas por tu aplicación. . Enviar por correo electrónico / Skype estas cosas es inseguro y conduce al desorden. Almacenarlo en Google Docs compartido no está mal (si todos usan https), pero una aplicación dedicada a almacenar y compartir pequeños detalles como contraseñas sería ideal.
Cómo configurar variables de entorno en Heroku
Si tiene un solo entorno en Heroku:
-bash> heroku config:add HTTP_USER='herouser'
-bash> heroku config:add HTTP_USER='heropass'
Si tiene varios entornos en Heroku:
-bash> heroku config:add HTTP_USER='staguser' --remote staging
-bash> heroku config:add HTTP_PASS='stagpass' --remote staging
-bash> heroku config:add HTTP_USER='produser' --remote production
-bash> heroku config:add HTTP_PASS='prodpass' --remote production
Foreman y .env
Muchos desarrolladores usan Foreman (instalado con Heroku Toolbelt ) para ejecutar sus aplicaciones localmente (en lugar de usar Apache / Passenger o rails server
). Foreman y Heroku utilizan Procfile
para declarar qué comandos ejecuta su aplicación , por lo que la transición del desarrollador local a Heroku es perfecta en ese sentido. Utilizo Foreman y Heroku en todos los proyectos de Rails, por lo que esta conveniencia es excelente. Pero aquí está la cuestión ... Foreman carga las variables de entorno almacenadas a /.env
través de dotenv pero, lamentablemente, dotenv esencialmente solo analiza el archivo en busca de key=value
pares; esos pares no se convierten en variables allí mismo, por lo que no puede hacer referencia a las variables ya configuradas (para mantener las cosas SECAS), ni puede hacer "Ruby" allí (como se señaló anteriormente con los condicionales), que puede hacer en /config/app_environment_variables.rb
. Por ejemplo, en términos de mantener las cosas SECAS, a veces hago cosas como esta:
ENV['SUPPORT_EMAIL']='Company Support <support@company.com>'
ENV['MAILER_DEFAULT_FROM'] = ENV['SUPPORT_EMAIL']
ENV['MAILER_DEFAULT_TO'] = ENV['SUPPORT_EMAIL']
Por lo tanto, uso Foreman para ejecutar mis aplicaciones localmente, pero no uso su .env
archivo para cargar variables de entorno; en lugar de eso, utilizo Foreman junto con el /config/app_environment_variables.rb
enfoque descrito anteriormente.
export admin_password="secret"
, noexport admin_password = "secret"
.