¿Cómo logras mantener las credenciales fuera del código fuente que se puede consultar públicamente?

Question

Digamos que desea mostrar el código fuente de un archivo de configuración pero no desea que aparezcan 3-4 líneas en el código fuente público. ¿Cambia manualmente esas variables o hay algunos trucos que usa, como incluirlos en otro archivo separado e incluir eso en la configuración principal?

¿O es más común simplemente no rastrear e incluir ese archivo en el repositorio?

Answer 1

La forma en que abordo este problema, y ​​tengo que lidiar con ella en casi todos los proyectos en los que trabajo, es mediante el uso de un patrón que elegí de alguien. En este patrón, que no solo se puede utilizar para evitar que las credenciales estén bajo control de versión, sino también para segregar configuraciones específicas del entorno/plataforma, el archivo de configuración principal, que está bajo control de versión, importa un archivo de configuración secundario que es acertadamente llamado "local_settings". Este archivo "local_settings" no está bajo control de versiones, y para cada plataforma en la que se implementa el origen, se crea un archivo local_settings específico por separado, adaptado solo a esa plataforma.

Le daré un ejemplo de cómo hago esto comúnmente para mis proyectos de Django/Python. Hay un archivo central settings.py por proyecto, que está bajo control de versión, y una plataforma (tal vez la plataforma no es la terminología correcta para usar aquí) archivo específico local_settings.py. El archivo local_settings.py ha sido importada desde dentro del archivo settings.py, donde las diferentes variables de ajuste se definen de la siguiente manera:

import local_settings 

DATABASE_USER = local_settings.db_user 
DATABASE_PASSWORD = local_settings.db_pass 

Y, como ejemplo para ir junto con el fragmento anterior, el archivo local_settings.py se define así:

db_user = 'user' 
db_pass = 'pass' 

He encontrado este patrón cuando se trata del problema en cuestión para que funcione muy bien.

Answer 2

Depende del contexto, pero una solución común es tener un application.cfg.sample que no contenga información confidencial. Este archivo está en el repositorio, etc. Cuando realmente implementa la aplicación, copia ese archivo al application.cfg y edita las contraseñas, etc.

Otro enfoque es permitir que los valores de ejemplo funcionen para su desarrollo, pero sin sentido , es decir:

host: localhost 
username: user 
password: test 

en realidad, esto podría ser una cuenta de base de datos válida o lo que sea en su estación de trabajo de desarrollo, pero el usuario no puede pensar que se trata y la información no es sensible.

Answer 3

Simplemente reemplace las variables con ejemplos.

SETTINGS = { 
    username: 'test', 
    password: 'mypass' 
} 

etc.

Answer 4

Usted podría no comprobar el archivo en, si es sólo un ajuste válido para una configuración local realmente no hay punto de incluirlo en el código de fuente pública o hacer lo más inteligente y encriptar la información (en el caso de un archivo de configuración asp).