2014-05-18 20 views
29

Ho recentemente distribuito un'applicazione e ottenuto un errore interno del server a causa della produzione mancante secret_key_base. Dopo ore di test, sono riuscito a risolvere questo problema con due metodi:Produzione mancante secret_key_base in rotaie

Metodo 1:

Ho generato un nuovo SECRET_KEY con rake secret e sostituirlo con <%= ENV["SECRET_KEY_BASE"] %> in secrets.yml. Ha distribuito di nuovo l'app e questa volta ha funzionato. Ma penso che questo metodo sia sbagliato.

Metodo 2:

Ho generato un nuovo SECRET_KEY con rake secret e aggiunta environments/production.rb come config.secret_key_base = 'd1f4810e662acf46a33960e3aa5bd0************************, senza modificare secrets.yml (default è production: <%= ENV["SECRET_KEY_BASE"] %>). Distribuito di nuovo l'app e funziona correttamente.

Le mie domande:

  1. Quale metodo è il migliore?
  2. Se il secondo metodo è corretto, perché rails non genera un secret_key_base in production.rb per impostazione predefinita?
  3. C'è qualche altro metodo per farlo?

risposta

29

Ho finalmente trovato il metodo corretto. Nessuno dei metodi menzionati in questione è quello corretto.

Metodo corretto:

Noi stessi dovrebbe generare una chiave segreta (da rake secret) quindi creare un variabili d'ambiente per SECRET_KEY_BASE eseguendo seguente comando dal prompt dei comandi:

rhc set-env SECRET_KEY_BASE=3dc8b0885b3043c0e38aa2e1dc64******************** -a myapp 

dopo l'esecuzione di questo comando , connettiti al tuo server tramite SSH ed esegui env quindi dovresti vedere il tuo SECRET_KEY_BASE nell'elenco.

Ora riavvia l'app rhc app-stop myapp e rhc app-start myapp, quindi sei a posto.

+0

Questo metodo rhc è utilizzabile solo quando si effettua l'hosting su openshift.redhat.com? –

+0

È possibile trovare il metodo appropriato per ciascun servizio nei suoi documenti. Ad esempio per heroku è possibile controllare questa pagina: https://devcenter.heroku.com/articles/config-vars – user3631047

+0

Alla fine ho finito col radunare un segreto sul mio VPS e inserendolo nel mio file secrets.yml. –

0

Il metodo 1 è corretto. Non vuoi memorizzare i tuoi segreti nel codice.

+0

Perché no? Risponde a tutte e 3 le domande: "Le mie domande: Quale metodo è il migliore? Se il secondo metodo è corretto, perché le rotaie non generano un secret_key_base in production.rb di default? C'è qualche altro metodo per farlo? " Oltre a ciò, spiega perché. –

+0

Se non si dispone del codice nel repository pubblico o se si trova nel repository pubblico, è possibile ignorarlo con gitignore –

+0

Anche con un repository privato, è un rischio per la sicurezza archiviare segreti di produzione nel controllo del codice sorgente. Solo l'ambiente di runtime di produzione "ha bisogno di sapere" quei segreti, ma con un VCS ora ci sono copie extra su tutti gli host che hanno un checkout/clone del repository, comprese le unità di sviluppo, gli host CI, ecc. Ciò rende molto più difficile proteggere (o addirittura capire) la vera superficie di esposizione dei segreti di produzione. –

3

Se sei su una normale macchina Ubuntu, inserisci export SECRET_KEY_BASE=" <<< output from rake secret here >>> " nel tuo ~/.bashrc.

Eseguire source ~/.bashrc e riavviare l'app.

2

C'è un'altra opzione che dovrebbe essere un po 'più sicura e cioè aggiungerla al file di configurazione di Apache/Nginx. Sto usando Apache e ho appena usato:

SetEnv SECRET_KEY_BASE my_secret

Poi basta lasciare i segreti.il file yml impostato su: produzione: <% = ENV [ "SECRET_KEY_BASE"]%>

Per un web server di produzione non sono sicuro che sia valido per ritenere che un file .bashrc viene eseguito e otterrà la variabile ENV impostare, ma penso che in questo modo è certo di impostarlo. Non sono esperto ed è così pronto ad avere rischi o ragioni per cui non è una buona idea indicata da me.

Problemi correlati