Come riesci a mantenere le credenziali al di fuori del codice sorgente consultabile dal pubblico?

Question

Supponiamo che vogliate mostrare il codice sorgente per un file di impostazioni, ma non volete che vengano visualizzate 3-4 linee nel codice sorgente pubblico. Sostituisci manualmente quelle variabili o ci sono alcuni trucchi che usi, come includerli in un altro file separato e includerlo nel conf principale?

Oppure è più comune semplicemente non tracciare e includere quel file nel repository?

Answer 1

Il modo in cui affronta questo problema, e devo affrontarlo in quasi tutti i progetti su cui lavoro, è quello di utilizzare un modello scelto da qualcuno. In questo modello, che non può essere utilizzato solo per mantenere le credenziali non sotto controllo di versione ma anche per separare le impostazioni specifiche dell'ambiente/piattaforma, il file delle impostazioni principali, che è sotto controllo di versione, importa un file di impostazioni secondario che è opportunamente chiamato "local_settings". Questo file "local_settings" non viene messo sotto controllo di versione e, per ogni piattaforma su cui viene distribuita l'origine, viene creato un file specifico local_settings separato, adattato solo a quella piattaforma.

Ti darò un esempio di come faccio comunemente questo per i miei progetti Django/Python. C'è un file centrale, per progetto settings.py, che è sotto controllo di versione, e una piattaforma (forse la piattaforma non è proprio la terminologia giusta da usare qui) specifico local_settings.py. Il file local_settings.py è importata da all'interno del file settings.py, dove diverse variabili di impostazione vengono definiti nel seguente modo:

import local_settings 

DATABASE_USER = local_settings.db_user 
DATABASE_PASSWORD = local_settings.db_pass 

E, come esempio di andare avanti con frammento di sopra, il file local_settings.py viene definito così:

db_user = 'user' 
db_pass = 'pass' 

Ho trovato questo modello quando si tratta del problema in questione per funzionare davvero bene.

Answer 2

Dipende dal contesto, ma una soluzione comune è quella di avere un application.cfg.sample che non contenga informazioni sensibili. Questo file si trova nel repository, ecc. Quando si distribuisce l'applicazione, si copia quel file in application.cfg e si modificano nelle password, ecc.

Un altro approccio consiste nel lasciare che i valori di esempio funzionino per lo sviluppo, ma non hanno senso , vale a dire:

host: localhost 
username: user 
password: test 

Questo potrebbe in realtà essere un account di database valido o qualsiasi altra cosa sulla workstation di sviluppo, ma l'utente non potrebbe supporre che si tratta e le informazioni sono poco sensibili.

Answer 3

Sostituire semplicemente le variabili con quelle di esempio.

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

ecc

Answer 4

Si potrebbe o non controllare il file in, se il suo solo un'impostazione valida per una configurazione locale non c'è davvero nessun punto di includere nel codice sorgente pubblico o fare la cosa intelligente e crittografare le informazioni (nel caso di un file di impostazioni asp).