Nascondi le informazioni di autenticazione su Github

4

Quando crei un progetto che ha una sorta di informazione che deve essere privata (dettagli di autenticazione, ecc.), ma vuoi usare un repository pubblico come Github, c'è qualcosa che può essere fatto per mantenere queste cose private?

Tutto quello che posso davvero pensare è ignorare il file che contiene questi dati, ma se hai bisogno di cambiare qualcosa, ha bisogno di cambiare ovunque che sia estratto, rendendo inutile il VCS. Lo stesso problema con i ripristini ecc.

O questo è qualcosa che non può essere evitato facilmente quando si utilizza un repo pubblico?

    
posta TMH 24.09.2015 - 11:02
fonte

1 risposta

6

Ci sono un paio di modi diversi per affrontare questo problema. Tutto dipende dalle tue preferenze personali.

Non commettere file di configurazione

Questo è probabilmente il più semplice, anche se devi assicurarti di non commettere mai accidentalmente qualcosa con le informazioni di configurazione al suo interno. Con git, una volta che è stato commesso, spinto o biforcato è praticamente impossibile rimuoverlo. Se hai perso qualcosa in un file di configurazione che è stato inserito, considera tali informazioni compromesse.

Il principale svantaggio è che devi mantenere una sorta di documentazione sulla struttura e le voci necessarie nel file di configurazione. Distribuire l'applicazione significa creare un file di configurazione per il proprio ambiente. Una nuova versione che aggiunge un'opzione di configurazione richiederà una sorta di documentazione sul processo di distribuzione per la nuova versione per assicurarsi che questa opzione sia impostata.

Impegna un file sandbox

Molti progetti favoriscono un approccio in cui è possibile verificare, creare ed eseguire un'applicazione senza la necessità di eseguire alcuna configurazione. È possibile ottenere ciò fornendo un file di configurazione predefinito. Per il tuo database, questo file potrebbe semplicemente puntare a un server di database localhost con 'myproject_user' come username e 'myproject_password' come password per 'myproject_db'. Questo ha il vantaggio di fornire un file di configurazione predefinito con tutte le opzioni presenti E fa parte del codice perché viene eseguito con l'applicazione, diversamente dalla documentazione.

Il rovescio della medaglia è che in questo caso le persone che controllano l'applicazione devono configurare il loro ambiente per farlo corrispondere o comunque modificare le impostazioni di configurazione. Non risolve il problema con il dover ricordare di impostare i valori di configurazione anche sulla distribuzione.

Fornisci un file parameters.dist che viene controllato in fase di distribuzione

Framework come Symfony in realtà i file di configurazione della versione avendo un file parameters.yml.dist. (vedi link ). Questo è un file di modello che contiene semplicemente la struttura del file di configurazione, senza alcun valore, e durante la distribuzione confronta il file parameters.yml esistente con il file parameters.yml.dist distribuito. Le voci obsolete vengono eliminate e le nuove voci che richiedono un prompt di valore alla persona che distribuisce l'app per un valore.

Questo è un approccio solido per grandi applicazioni e framework che saranno utilizzati in altre applicazioni o da parti esterne, ma potrebbe essere eccessivo per le applicazioni più piccole dove la distribuzione è spesso un semplice copia / passato o upload FTP e puoi seguire una distribuzione -documento che delinea le voci che è necessario modificare.

    
risposta data 24.09.2015 - 11:22
fonte

Leggi altre domande sui tag