2010-12-10 3 views
7

Nuovo per binari, open source e pronto per la distribuzione in un ambiente di produzione, ho alcune considerazioni sulla sicurezza.Gestione della sicurezza per un'applicazione open source rails 3 memorizzata su github

Come gestire il database.yml è coperto abbastanza bene da, how-to-manage-rails-database-yml

Ma dal mio punto di vista ci sono più le impostazioni di configurazione in un normale applicazione rotaie che non dovrebbero essere ospitati in un repository github pubblico e distribuito alla produzione ad es

  • devise.rb -> config.pepper
  • secret_token.rb -> Application.config.secret_token
  • Capistrano -> deploy.rb
  • ...

Aggiunta config/****/* per .gitignore non solo impedirebbe ai nuovi sviluppatori di installare bundle install, db: create, db: migrate, rails server ma anche di mantenere aggiornata la configurazione di produzione se una nuova gemma con un inizializzatore è installare guidato.

Un'altra possibilità sarebbe aggiungere un environment.yml con configurazione sensibile, come database.yml dove la configurazione sensibile negli inizializzatori verrà sovrascritta?

Ciò renderà più semplice l'avvio e il funzionamento dopo un checkout pulito e l'ambiente di produzione sarà facile da gestire.

Qualche idea su come affrontare i miei problemi sopra?

risposta

5

Di solito inserisco dati "sicuri" in questi file, che di solito funzionano per scopi di sviluppo. Ma nella produzione I link simbolico i file in un'altra posizione con Capistrano, in questo modo:

invoke_command "ln -sf #{shared_path}/database.yml #{release_path}/config/database.yml" 

Così nel server di produzione Ho un gruppo di file che sostituiscono i file nel controllo del codice sorgente. Non lavoro nemmeno con lo database.yml.example, solo con un certo numero di default predefinito database.yml che gli sviluppatori sono d'accordo nell'usare nello sviluppo e nel test.

per preferenze individuali, come chiavi API, di solito creare un config/settings.yml e leggerli da dentro l'inizializzatore:

SETTINGS = YAML.load(IO.read(Rails.root.join("config", "settings.yml"))) 
YourApp::Application.config.secret_token = SETTINGS["secret_token"] 
+0

Grazie per la risposta rapida e ci si sente bene che la soluzione è simile al mio immaginario. Ci sono altre impostazioni sensibili in un sito di binari di vaniglia? Darò alla tua soluzione una prova, è semplice e penso che si adatta alle mie esigenze per iniziare. – orjan

+0

Non so come il link simbolico possa funzionare per te quando stai eseguendo "cap deploy: migrations" dato che sono in esecuzione contro la release e non la dir corrente? Avevo bisogno di cambiare il link simbolico per eseguire "ln -nfs # {shared_path} /config/database.yml # {release_path} /config/database.yml" orjan

+0

woops, your right :) – iain