Управление безопасностью приложения rails 3 с открытым исходным кодом, хранящегося на github

Новичок в rails, с открытым исходным кодом и вскоре готовый к развертыванию в производственной среде, у меня есть некоторые соображения по поводу безопасности.

О том, как обращаться с файлом database.yml, довольно хорошо рассказывается в how-to-manage-rails. -база данных-yml

Но, с моей точки зрения, в обычном приложении rails есть больше параметров конфигурации, которые не следует размещать в общедоступном репозитории github и развертывать в рабочей среде, например.

  • devise.rb -> config.pepper
  • secret_token.rb -> Application.config.secret_token
  • капистрано -> deploy.rb
  • ...

Добавление config/****/* в .gitignore не только не позволит новым разработчикам установить пакет, db:create, db:migrate, rails server, но и будет поддерживать рабочую конфигурацию в актуальном состоянии, если установлен новый гем с инициализатором.

Другой возможностью было бы добавить environment.yml с конфиденциальной конфигурацией, такой как database.yml, где конфиденциальная конфигурация в инициализаторах будет переопределена?

Это облегчит запуск и работу после чистой проверки, а производственную среду будет легко поддерживать.

Любые идеи, как подойти к моим проблемам выше?


github ruby-on-rails open-source capistrano
person orjan    schedule 10.12.2010    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Я обычно помещаю в эти файлы «безопасные» данные, которые обычно подходят для целей разработки. Но в производстве я символизирую файлы в другом месте с помощью capistrano, например:

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

Итак, на рабочем сервере у меня есть куча файлов, которые переопределяют файлы в системе управления версиями. Я даже не работаю с database.yml.example, просто с некоторым разумным значением по умолчанию database.yml, которое разработчики соглашаются использовать при разработке и тестировании.

Для отдельных настроек, таких как ключи API, я обычно создаю config/settings.yml и читаю их внутри инициализатора:

SETTINGS = YAML.load(IO.read(Rails.root.join("config", "settings.yml")))
YourApp::Application.config.secret_token = SETTINGS["secret_token"]
person iain    schedule 10.12.2010
comment
Спасибо за ваш быстрый ответ, и мне приятно, что ваше решение похоже на мое воображаемое. Есть ли какие-либо другие чувствительные настройки на сайте vanilla rails? Я попробую ваше решение, оно простое, и я думаю, что оно будет соответствовать моим потребностям для начала. - person orjan; 10.12.2010
comment
Я не знаю, как символическая ссылка может работать для вас, когда вы используете cap deploy:migrations, поскольку они работают с выпуском, а не с текущим каталогом? Мне нужно было изменить символическую ссылку на ›run ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml‹, как в примере в stackoverflow.com/questions/1449836/ - person orjan; 11.12.2010