2010-12-10 83 views
7

Nouveau sur les rails, open source et bientôt prêt à être déployé dans un environnement de production, j'ai quelques considérations de sécurité.Gestion de la sécurité pour les rails open source 3 application stockée sur github

Comment gérer le database.yml est couvert assez bonne par, how-to-manage-rails-database-yml

Mais de mon point de vue, il y a plus de paramètres de configuration dans une application qui rails normale ne devrait pas être hébergé dans un dépôt GitHub public et déployé en production

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

Ajout config/****/* à .gitignore empêcherait non seulement les nouveaux développeurs de installer ensemble, db: create, db: migrate, rails serveur mais aussi de garder la configuration de production à jour si une nouvelle gemme avec un initialiseur est installer LED.

Une autre possibilité serait d'ajouter un environnement.yml avec une configuration sensible, comme database.yml où la configuration sensible dans les initialiseurs sera surchargée?

Cela facilitera la mise en service après une vérification de paiement et l'environnement de production sera facile à entretenir.

Des idées sur comment aborder mes problèmes ci-dessus?

Répondre

5

Je place généralement des données "sécurisées" dans ces fichiers, qui fonctionnent généralement à des fins de développement. Mais dans la production, je les fichiers vers un lien symbolique un autre endroit avec Capistrano, comme ceci:

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

Ainsi, dans le serveur de production, j'ai un tas de fichiers qui remplacent les fichiers dans le contrôle source. Je ne travaille même pas avec un database.yml.example, juste un certain défaut par défaut que les développeurs acceptent d'utiliser dans le développement et le test.

Pour les réglages individuels, comme les clés de l'API, je crée habituellement un config/settings.yml et de les lire à l'intérieur du initialiseur:

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

Merci pour votre réponse rapide et il se sent bien que votre solution est semblable à mon imaginaire. Y a-t-il d'autres paramètres sensibles dans un site de rails de vanille? Je vais essayer votre solution, c'est simple et je pense que cela correspondra à mes besoins pour commencer. – orjan

+0

Je ne sais pas comment le lien symbolique peut fonctionner pour vous lorsque vous exécutez "cap deploy: migrations" puisque les liens s'exécutent sur la version et non sur le répertoire en cours? J'avais besoin de changer le lien symbolique pour> exécuter "ln -nfs # {chemin_partagé} /config/database.yml # {chemin_d'accès} /config/database.yml" orjan

+0

woops, votre droite :) – iain