Какая польза от secret_key_base в рельсах 4

Я новичок в Rails 4 и не понимаю использование secret_key_base под config/secrets.yml в Rails 4. Не могли бы вы объяснить эту концепцию?

Кроме того, когда я работаю в производственной среде, мне предлагается установить secret_key с помощью devise.rb, config.secret_key и secret_key_base. Однако я могу сгенерировать новый секрет с помощью команды rake secret.

В чем разница между средой разработки и производственной средой?

Как это соответствует вновь сгенерированному secret_key, когда я добавляю его с secret_key_base каждый раз, когда я генерирую?

Как это защищает приложение с другими серверами?


person Mani David    schedule 21.08.2014    source источник
comment
Для читателей, использующих Ruby on Rails 5.2 или новее. secret_key_base по-прежнему используется, но вместо этого хранится в config/credentials.yml.enc. Этот файл зашифрован. Дополнительную информацию о новой системе учетных данных можно найти здесь или запустить rails credentials:help.   -  person 3limin4t0r    schedule 22.01.2020


Ответы (2)


Содержимое файла secret_token.rb включает длинную рандомизированную строку , которая используется для проверки целостности подписанных файлов cookie (например, сеансов пользователей, когда люди входят в ваше веб-приложение).

В Документация говорится:

Используйте существующую базу secret_key_base из инициализатора secret_token.rb, чтобы установить переменную среды SECRET_KEY_BASE для всех пользователей, запускающих приложение Rails в производственном режиме. В качестве альтернативы вы можете просто скопировать существующую базу секретных_ключей из инициализатора secret_token.rb в файл secrets.yml в разделе производства, заменив <%= ENV["SECRET_KEY_BASE"] %>.

Поскольку это важный файл, и вы не можете поместить его в .gitignore, считается хорошей практикой использовать переменную env для хранения значения secret_key_base:

создайте файл .env или .powenv и сохраните его как:

export SECRET_TOKEN="9489b3eee4eccf317ed77407553e8adc97baca7c74dc7ee33cd93e4c8b69477eea66eaedeb18af0be2679887c7c69c0a28c0fded0a71ea472a8c4laalal19cb"

А потом в config/initializers/secret_token.rb

YourAppName::Application.config.secret_key_base = if Rails.env.development? or Rails.env.test? # generate simple key for test and development environments
  ('a' * 30) # should be at least 30 chars long
else
  ENV['SECRET_TOKEN']
end

Эта статья (немного старая и) длинная, но действительно полная полезной информации по теме.


ОБНОВЛЕНИЕ 04.05.15

Начиная с Rails 4.2 больше нет файла secret_token.rb. По новому соглашению существует файл config/secrets.yml, предназначенный для хранения секретов приложения.

прочитайте, как обновить существующее приложение до версии 4.2.x в соответствии с к инновациям.


Технически цель secrect_key_base состоит в том, чтобы быть секретным вводом для метода приложения key_generator (проверьте Rails.application.key_generator).

key_generator приложения и, следовательно, secret_key_base используются тремя основными функциями в среде Rails:

  • Получение ключей для зашифрованных файлов cookie, которые доступны через cookies.encrypted.
  • Получение ключа для файлов cookie, подписанных HMAC, которые доступны через cookies.signed.
  • Получение ключей для всех именованных экземпляров приложения message_verifier.

Узнайте больше о каждом из трех в статья @michaeljcoyne.

person Andrey Deineko    schedule 21.08.2014
comment
Обратите внимание, что если вы используете что-то вроде Ansible или аналогичного для развертывания, вы можете заменить весь secret.yml во время производственного развертывания и gitignore config/secret.yml, если хотите. - person Kris; 19.07.2017
comment
Фактически, config/secrets.yml появился в Rails 4.1. - person Fumisky Wells; 20.09.2017
comment
Все это означает, что когда вы меняете secret_key_base, ваши пользователи выходят из системы. Как минимум. - person x-yuri; 22.07.2019

secret_key_base используется для шифрования и подписи сеанса

чтобы безопасно отправлять сеанс туда и обратно в куки


В Rails 4

  1. если ваше приложение называется Hello и
  2. вы установили session['a'] = 'b',

ваш файл cookie будет выглядеть примерно так:

_Hello_session=BAh7B0kiD3%3D%3D--dc40a55cd52fe32bb3b84ae0608956dfb5824689

что переводится как:

_Hello_session=<encrypted a=b>--<digital signature>

Файлы cookie устанавливаются сервером и сохраняются на стороне клиента, при этом браузер повторно отправляет установленные файлы cookie на сервер каждый раз, когда мы запрашиваем страницу.

Чтобы злоумышленники не могли понять строку a=b, она зашифрована.
Чтобы предотвратить подделку файлов cookie злоумышленниками, используется цифровая подпись.

В обоих случаях используется значение secret_key_base (для шифрования/дешифрования a=b и проверки цифровой подписи).

person lakesare    schedule 05.08.2015
comment
1. Насколько я знаю, данные сеанса сохраняются на сервере, а в файле cookie есть идентификатор сеанса. например. сохранить user_id в сеансе, браузер может видеть только session_id, в то время как после входа в систему сервер может узнать, какой пользователь отправляет запрос по session_id. Здесь вы говорите, что session['a'] = 'b' будет шифровать данные внутри файла cookie. Я не уверен, что вы путаетесь между сеансом и файлом cookie. 2. как браузер может расшифровать его, не зная secret_key_base и получить информацию? - person Damon Yuan; 19.07.2016
comment
извините, теперь я знаю, что рельсы используют сеанс на основе файлов cookie, что означает, что информация о сеансе хранится внутри файлов cookie. - person Damon Yuan; 23.07.2016
comment
да, сеансы на основе файлов cookie обеспечивают переносимость сеансов на распределенных серверах приложений и скорость - person hammady; 18.10.2017