software - ¿Qué se debe eliminar del control de fuente pública en Ruby on Rails?

ruby on rails website

Question

He estado buscando en la web, y no puedo encontrar ejemplos buenos / recientes de qué excluir de una nueva aplicación de vías públicas. Busco abrir mi aplicación de código abierto en GitHub y me pregunto qué tipos de datos deben eliminarse del control de código fuente.

Por lo que puedo decir, debería haber un archivo config/config.yml que tenga información privada. He estado buscando en los otros archivos, y parece que config/database.yml , config/intializers/secret_token.rb y config/initializers/session_store.rb también deberían excluirse.

¿Es una buena práctica excluir todos estos archivos por separado? ¿O hay una manera de tener toda la información definida en config/config.yml y ser llamada en cada uno de esos archivos? Además, ¿qué archivos y datos deben mantenerse privados y ocultos? ¿Son todos ellos?

Me pregunto qué enfoque debería tomar y cuál es la mejor práctica. ¡Gracias por cualquier ayuda!

Answer 1

He estado investigando esto recientemente también; Quería mantener la información confidencial oculta durante todo el proceso de enviar el código de fuente abierta a Github, luego enviarla automáticamente a Travis CI para su prueba, y luego de Travis se implementó automáticamente en Heroku . Aquí están todos los detalles de lo que he encontrado hasta ahora en varias preguntas y respuestas sobre , blogs, etc. que, con suerte, serán una referencia para usted, incluso si solo es para la configuración dentro de la aplicación Rails (omita cualquier {{ ... }} ya ves)

Descargo de responsabilidad: de ninguna manera soy un experto aquí, así que tenga en cuenta que probablemente hay mejores maneras de hacer esto que lo que estoy intentando. Me encantaría poder aprender algunos trucos nuevos en este hilo de preguntas y respuestas.

Dentro de la aplicación Rails

Actualmente utilizo la gema Figaro para ocultar información confidencial en las variables de entorno de ENV . En mi ( .gitignore d) config / application.yml , guardo la siguiente información:

# App keys
SECRET_TOKEN: # your rake secret generated token

development:
  DB_NAME: # your dev db name here
  DB_USER: # your dev db username here
  DB_PASSWORD: # your dev db password here

test:
  DB_NAME: # your test db name here
  DB_USER: # your test db username here
  DB_PASSWORD: # your test db password here

production:
  DB_NAME: # your prod db name here
  DB_USER: # your prod db username here
  DB_PASSWORD: # your prod db password here

# Third Party keys that you will reference in their relevant files
THIRD_PARTY_API_OR_LICENSE_KEY: # list of whatever api/license keys you use

( DB_NAME , DB_USER y DB_PASSWORD se utilizarán dinámicamente según el entorno en el que se ejecute su aplicación).

Una versión vacía del archivo anterior ( config / application.example.yml ) se envía a Github con algunas instrucciones sobre cómo completarlo.

Los archivos que se envían a Github y hacen referencia a estas variables se ven así:

config / database.yml
(Postgresql se usa aquí, pero debería poder cambiar la configuración de cualquier base de datos que use)

postgresql: &postgresql
  adapter: postgresql
  database: <%= ENV[''DB_NAME''] %>
  username: <%= ENV[''DB_USER''] %>
  password: <%= ENV[''DB_PASSWORD''] %>
  min_messages: ERROR

defaults: &defaults
  pool: 5
  timeout: 5000
  host: localhost
  <<: *<%= ENV[''DB''] || "postgresql" %>

development:
  <<: *defaults

test:
  <<: *defaults

production:
  <<: *defaults

config / initializers / secret_token.rb

if Rails.env.production? && ENV[''SECRET_TOKEN''].blank?
  raise ''SECRET_TOKEN environment variable must be set!''
end

YourApp::Application.config.secret_token = 
  ENV[''SECRET_TOKEN''] || {{WHATEVER_SECRET_TOKEN_RAILS_GENERATED_BY_DEFAULT}}

(Además, cualquier archivo que THIRD_PARTY_API_OR_LICENSE_KEY referencia a las THIRD_PARTY_API_OR_LICENSE_KEY tipo THIRD_PARTY_API_OR_LICENSE_KEY ).

Pruebas en Travis CI

Crea variables travis encriptadas usando la gema Travis . La clave API de Heroku y la URL de Heroku Git son necesarias si implementa directamente en Heroku desde un trabajador de Travis (consulte esta sección de preguntas y respuestas de para obtener más detalles), de lo contrario, puede omitirlas si la usa para realizar pruebas:

$ gem install travis
$ travis encrypt your_username/your_repo HEROKU_API_KEY={{YOUR_HEROKU_API_KEY}}
$ travis encrypt HEROKU_GIT_URL={{YOUR_HEROKU_GIT_URL}} # eg [email protected]:your_app.git
$ travis encrypt DB_NAME={{YOUR_DB_NAME_UNDER_TEST}} # eg your_app_test
$ travis encrypt DB_USER={{YOUR_DB_USER_UNDER_TEST}}
$ travis encrypt DB_PASSWORD={{YOUR_DB_PASSWORD_UNDER_TEST}}

(Además, cifre cualquier otra clave que pueda necesitar durante la prueba, si la hubiera ...)

Luego agrégalos a .travis.yml
(una vez más centrado en Postgresql, pero debería poder cambiar la configuración de cualquier base de datos que use)

env:
  global:
    - secure: {{YOUR_ENCRYPTED_HEROKU_API_KEY}}
    - secure: {{YOUR_ENCRYPTED_HEROKU_GIT_URL}}
    - secure: {{YOUR_ENCRYPTED_DB_NAME}}
    - secure: {{YOUR_ENCRYPTED_DB_USER}}
    - secure: {{YOUR_ENCRYPTED_DB_PASSWORD}}
  matrix:
    - DB: postgresql
before_script:
  - psql -c "create database $DB_NAME;" -U $DB_USER
  - RAILS_ENV=test bundle exec rake db:migrate
script:
  - bundle exec rspec spec/
after_success:
  - gem install heroku
  - git remote add heroku $HEROKU_GIT_URL
  # ... see link above for the rest of the config content

Las variables múltiples marcadas con el mismo nombre de secure están bien; aparecerán en la configuración como HEROKU_API_KEY=[secure] HEROKU_GIT_URL=[secure] etc.

Despliegue a Heroku

Use la tarea de rastrillo Heroku de Figaro para establecer automáticamente las variables de entorno que Heroku necesita ver en producción:

$ rake figaro:heroku

O bien, configurarlos manualmente:

$ heroku config:set SECRET_TOKEN={{YOUR_SECRET_TOKEN}}
$ heroku config:set DB_NAME={{YOUR_DB_NAME_UNDER_PRODUCTION}} # eg your_app_production
$ heroku config:set DB_USER={{YOUR_DB_USER_UNDER_PRODUCTION}}
$ heroku config:set DB_PASSWORD={{YOUR_DB_PASSWORD_UNDER_PRODUCTION}}
$ heroku config:set THIRD_PARTY_API_OR_LICENSE_KEY={{YOUR_THIRD_PARTY_API_OR_LICENSE_KEY}}

Luego, intente un despliegue.

Eso es todo lo que tengo por ahora. No estoy seguro en este momento si debería ocultar más información o si no la estoy ocultando lo suficientemente bien, pero es un trabajo en progreso.

Answer 2

Obtendrás diferentes opiniones. En mi humilde opinión, es una buena práctica incluir estos archivos, pero omita el contenido secreto de ellos. Documente lo que está haciendo para que los desarrolladores que son nuevos en su proyecto sepan lo que necesitan completar.

Phusion tiene una buena publicación en el blog sobre cómo manejar el secreto de la sesión de Rails y las ventajas y desventajas que puede hacer para incluir o excluir información:

http://blog.phusion.nl/2013/01/04/securing-the-rails-session-secret/#.URYPXekTMak

Mi forma favorita de documentar esto es mediante una tarea de "configuración de rake". Puede hacer que la tarea imprima lo que el desarrollador debe hacer; en otras palabras, no necesita automatizarlo todo (aunque eso es bueno si puede hacerlo).

Si desea obtener fantasía, pida a sus archivos que lean la configuración secreta de un directorio compartido /, que también habilita la vinculación de la implementación. Esto se describe en el blog de Phusion también. Así es como construyo aplicaciones que necesitan ser implementadas con frecuencia.