Подтвердить что ты не робот

Что должно быть удалено из государственного источника управления в Ruby on Rails?

Я искал в Интернете, и я не могу найти никаких хороших/недавних примеров того, что следует исключать из нового общедоступного приложения rails. Я хочу открыть исходное приложение для своего приложения в GitHub, и мне интересно, какие типы данных следует удалить из исходного управления.

Из того, что я могу сказать, должен быть файл config/config.yml, который имеет личную информацию. Я просматривал другие файлы, и это выглядит так: config/database.yml, config/intializers/secret_token.rb и config/initializers/session_store.rb также должны быть исключены?

Лучше ли вообще исключать все эти файлы? Или есть способ получить информацию, определенную в config/config.yml, и вызываться в каждом из этих файлов? Кроме того, какие файлы и данные следует хранить конфиденциальными и скрытыми? Это все они?

Мне просто интересно, какой подход я должен предпринять и какова наилучшая практика. Спасибо за любую помощь!

4b9b3361

Ответ 1

Я изучал это недавно; Я хотел, чтобы конфиденциальная информация скрывалась в процессе нажатия на открытый исходный код Github, а затем автоматически переводилась в Travis CI для тестирования, затем из Travis автоматически развертывается в Heroku. Ниже приведены все детали того, что я нашел до сих пор, глядя на различные StackOverflow Q & As, blogs и т.д., Которые, надеюсь, будут служить для вас ссылкой, даже если только для конфигурации внутри приложения Rails (опустите любой {{ ... }} см)

Отказ от ответственности: я ни в коем случае не эксперт, поэтому, пожалуйста, имейте в виду, что есть, вероятно, лучшие способы сделать это, чем то, что я пытаюсь. Мне бы хотелось узнать некоторые новые трюки в этом потоке Q & A.


Внутри приложения Rails

В настоящее время я использую Figaro gem, чтобы скрыть конфиденциальную информацию в переменных среды ENV. В моей (.gitignore d) config/application.yml я сохраняю следующую информацию:

# App keys
SECRET_TOKEN: # your rake secret generated token

development:
  DB_NAME: # your dev db name here
  DB_USER: # your dev db username here
  DB_PASSWORD: # your dev db password here

test:
  DB_NAME: # your test db name here
  DB_USER: # your test db username here
  DB_PASSWORD: # your test db password here

production:
  DB_NAME: # your prod db name here
  DB_USER: # your prod db username here
  DB_PASSWORD: # your prod db password here

# Third Party keys that you will reference in their relevant files
THIRD_PARTY_API_OR_LICENSE_KEY: # list of whatever api/license keys you use

(DB_NAME, DB_USER и DB_PASSWORD будут использоваться динамически в зависимости от среды, в которой работает ваше приложение).

Пустая версия вышеуказанного файла (config/application.example.yml) помещается в Github с некоторыми инструкциями о том, как его заполнить.

Файлы, которые помещаются в Github и ссылаются на эти переменные, выглядят следующим образом:

конфиг /database.yml
(Postgresql используется здесь, но вы должны иметь возможность изменять настройки для любой используемой базы данных)

postgresql: &postgresql
  adapter: postgresql
  database: <%= ENV['DB_NAME'] %>
  username: <%= ENV['DB_USER'] %>
  password: <%= ENV['DB_PASSWORD'] %>
  min_messages: ERROR

defaults: &defaults
  pool: 5
  timeout: 5000
  host: localhost
  <<: *<%= ENV['DB'] || "postgresql" %>

development:
  <<: *defaults

test:
  <<: *defaults

production:
  <<: *defaults

конфигурации/инициализаторы/secret_token.rb

if Rails.env.production? && ENV['SECRET_TOKEN'].blank?
  raise 'SECRET_TOKEN environment variable must be set!'
end

YourApp::Application.config.secret_token = 
  ENV['SECRET_TOKEN'] || {{WHATEVER_SECRET_TOKEN_RAILS_GENERATED_BY_DEFAULT}}

(Кроме того, любые файлы будут ссылаться на клавиши THIRD_PARTY_API_OR_LICENSE_KEY -type.)

Тестирование на Travis CI

Создайте зашифрованные переменные travis, используя драгоценный камень Тревиша. Ключ API Heroku и URL Heroku Git необходимы, если вы разворачиваете прямо в Heroku от работника Travis (см. этот StackOverflow Q & A для подробностей), в противном случае вы можете опустите их, если вы просто используете его для тестирования:

$ gem install travis
$ travis encrypt your_username/your_repo HEROKU_API_KEY={{YOUR_HEROKU_API_KEY}}
$ travis encrypt HEROKU_GIT_URL={{YOUR_HEROKU_GIT_URL}} # eg [email protected]:your_app.git
$ travis encrypt DB_NAME={{YOUR_DB_NAME_UNDER_TEST}} # eg your_app_test
$ travis encrypt DB_USER={{YOUR_DB_USER_UNDER_TEST}}
$ travis encrypt DB_PASSWORD={{YOUR_DB_PASSWORD_UNDER_TEST}}

(Кроме того, зашифруйте любые другие ключи, которые могут понадобиться во время тестирования, если они есть...)

Затем добавьте их в .travis.yml
(еще раз Postgresql-сфокусированный, но вы должны иметь возможность изменять настройки для любой используемой базы данных)

env:
  global:
    - secure: {{YOUR_ENCRYPTED_HEROKU_API_KEY}}
    - secure: {{YOUR_ENCRYPTED_HEROKU_GIT_URL}}
    - secure: {{YOUR_ENCRYPTED_DB_NAME}}
    - secure: {{YOUR_ENCRYPTED_DB_USER}}
    - secure: {{YOUR_ENCRYPTED_DB_PASSWORD}}
  matrix:
    - DB: postgresql
before_script:
  - psql -c "create database $DB_NAME;" -U $DB_USER
  - RAILS_ENV=test bundle exec rake db:migrate
script:
  - bundle exec rspec spec/
after_success:
  - gem install heroku
  - git remote add heroku $HEROKU_GIT_URL
  # ... see link above for the rest of the config content

Несколько переменных, отмеченных с тем же именем secure, являются точными; они появятся в конфигурации как HEROKU_API_KEY=[secure] HEROKU_GIT_URL=[secure] и т.д.

Развертывание в Heroku

Используйте задачу рейга Figaro Heroku для автоматической установки переменных окружения, которые Heroku должен видеть в процессе производства:

$ rake figaro:heroku

Или, установите их вручную:

$ heroku config:set SECRET_TOKEN={{YOUR_SECRET_TOKEN}}
$ heroku config:set DB_NAME={{YOUR_DB_NAME_UNDER_PRODUCTION}} # eg your_app_production
$ heroku config:set DB_USER={{YOUR_DB_USER_UNDER_PRODUCTION}}
$ heroku config:set DB_PASSWORD={{YOUR_DB_PASSWORD_UNDER_PRODUCTION}}
$ heroku config:set THIRD_PARTY_API_OR_LICENSE_KEY={{YOUR_THIRD_PARTY_API_OR_LICENSE_KEY}}

Затем выполните попытку развертывания.


Это все, что у меня есть сейчас. Не уверен в данный момент, если я буду скрывать больше информации, или если я не скрываю ее достаточно хорошо, но это незавершенная работа.

Ответ 2

Вы получите разные мнения. ИМХО, лучше всего включить эти файлы, но опустить секретный контент из них. Документируйте, что вы делаете, чтобы разработчики, которые не знакомы с вашим проектом, знают, что им нужно заполнить.

Phusion имеет хорошее сообщение в блоге о том, как обрабатывать секрет сеанса Rails, и компромиссы, которые вы можете включить, чтобы включать или исключать информацию:

http://blog.phusion.nl/2013/01/04/securing-the-rails-session-secret/#.URYPXekTMak

Мой любимый способ документировать их - это использование задачи "Настройка рейка". Вы можете заставить задачу распечатать то, что нужно сделать разработчику, другими словами, вам не нужно автоматизировать все это (хотя это хорошо, если вы в состоянии это сделать).

Если вы хотите получить фантазию, попросите ваши файлы прочитать секретные настройки из каталога shared/, что также позволяет использовать символическую привязку. Это описано в блоге Phusion. Вот как я создаю приложения, которые нужно часто развертывать.