¿Qué pasa si algún código fuente de un proyecto de rieles debe oscurecerse incluso para un proyecto de código abierto?

Question

Esta fue una tarea difícil de buscar. Si tengo un proyecto de aplicación web de rieles de código abierto cuyo código fuente está alojado públicamente, como en GitHub, ¿qué información debe ocultarse o intercambiarse si esa aplicación se va a ejecutar en producción en un sitio web público? Mi suposición es que cosas como config/initilizers/secret_token.rb, cualquier cosa de salting de autenticación y la información de inicio de sesión de la base de datos no deberían ser las mismas en producción que en desarrollo. ¿Qué otras precauciones deberían tomarse para garantizar que el sitio de producción no sea vulnerable a personas que manipulan las sesiones o cualquier otra cosa que no esté considerando? Fuentes

Answer 1

carriles específicos de información sensible

Scrub información sensible fuera de:

• config/environments/*.rb
• config/initializers/cookie_verification_secret.rb
• config/initializers/secret_token.rb
• config/initializers/session_store.rb
• los archivos añadidos a apoyar a las bibliotecas de terceros, tales como config/memcached.yml
• config/database.yml
• db/seeds.rb
• cualquier tarea en el rastrillo de lib/tasks.
• test/fixtures/*

cambios generales

La inclusión de esta sólo porque creo que es una buena lista de cosas a tener en cuenta para la liberación de software de código abierto que también tiene en la producción.

• Retire la información sensible:
  • sales contraseña
  • credenciales de usuario por defecto pobladas por código o semillas
  información
  • autenticación para cualquier servidor externo o servicio
    • bases de datos
    • APIs de terceros
    • eCommerse solutions
  • cualquier dato cabeza de serie, que potencialmente dar a conocer secretos comerciales
• Código de ensayo a fondo para hazañas. Si están en su código y su código está disponible para el público, las personas los encontrarán y sabrán cómo poner en peligro su sitio.
• Limpiar el código. El código es una forma de publicidad para su sitio; es una de las muchas cosas que representarán su sitio/compañía. Asegúrese de cambiar los nombres de variables/funciones/mensajes de error/datos sin identificar/etc que fueron escritos con humor o frustración, pero que se verían mal para el público.
• Contribuya activamente con sus mejoras y correcciones de errores al proyecto y responda a las solicitudes externas de correcciones/mejoras o incluso solicitudes de extracción para aquellos que han resuelto un problema ellos mismos. Esto mantiene el proyecto activo y también ayuda con el ángulo publicitario.
• Asegúrese de otorgar crédito donde se debe crédito. Ahora que su código es público, las personas sabrán si han utilizado códigos/bibliotecas de terceros. Si dicho código viene con cláusulas de atribución en sus acuerdos de licencia, asegúrese de que su proyecto cumpla con esos acuerdos.

Answer 2

La respuesta anterior de Shaun es muy minuciosa.

Además, me gustaría recomendar el uso de .gitignore a su ventaja para evitar que se cometan archivos con información confidencial.

Cualquier archivo que contenga claves o contraseñas de API, etc. debe estar en .gitignore. Típicamente, esto incluye:

database.yml 
log/* 
tmp/* 

Si tiene claves de la API asignados a las constantes en los archivos de código, lo recomiendo poner todas las claves de la API, contraseñas, etc. en un archivo site.yml. A continuación, agregue este archivo a .gitignore y agregue un inicializador para analizar este archivo en una constante. Usa esa constante para acceder a los datos secretos.

Por ejemplo:

config/site.yml:

hoptoad_api_key: ABCDEF1234567890 

config/inicializador/01_site.rb

SITE = HashWithIndifferentAccess.new(YAML.load(File.open(File.join(Rails.root, 'config', 'site.yml')))) 

config/inicializador/hoptoad.rb

HoptoadNotifier.configure do |config| 
    config.api_key = SITE['hoptoad_api_key'] 
end 

Tenga en cuenta que la inicialización Los controladores se ejecutan en orden alfabético. Si necesita la constante SITE en otros inicializadores, asegúrese de nombrar el archivo que lee la configuración con un número inicial para que se ejecute primero.

Para ser más fácil de usar para un proyecto de código abierto, se debe incluir un archivo database.yml.sample y site.yml.sample con ejemplos y/o explicar las configuraciones necesarias en su README.