私はRails 4を初めて使用しますが、Rails 4.のsecret_key_base
の下でconfig/secrets.yml
を使用することを理解していません。この概念を説明してください。
また、実稼働環境で作業しているときに、secret_key
、devise.rb
、およびconfig.secret_key
でsecret_key_base
を設定するように求められます。ただし、rake secret
コマンドを使用して新しいシークレットを生成できます。
開発環境と本番環境の違いは何ですか?
生成するたびにsecret_key
で追加すると、新しく生成されたsecret_key_base
とどのように一致しますか?
他のサーバーでアプリケーションをどのように保護しますか?
secret_token.rb
ファイルのコンテンツには、署名済みCookieの整合性を検証するために使用される長いランダム化された文字列が含まれています( (ユーザーがウェブアプリにログインしたときのユーザーセッションなど)。
ドキュメント 言います:
secret_token.rb
イニシャライザーの既存のsecret_key_baseを使用して、実稼働モードでRailsアプリを実行するユーザーにSECRET_KEY_BASE環境変数を設定します。または、既存のsecret_key_baseをsecret_token.rb
初期化子からproductionセクションの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
この記事 は(少し古くて)長いですが、このトピックに関する有用な情報でいっぱいです。
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フレームワーク内の3つのコア機能によって使用されます。
cookies.encrypted
を介してアクセス可能な暗号化されたCookieのキーを取得します。cookies.signed
経由でアクセス可能なHMAC署名済みCookieのキーを取得します。message_verifier
インスタンスのキーを導出します。@ michaeljcoyneによる記事 の3つのそれぞれについて詳しく調べてください。
Rails 4では、
Hello
の場合、およびsession['a'] = 'b'
を設定した場合、cookieは次のようになります。
_Hello_session=BAh7B0kiD3%3D%3D--dc40a55cd52fe32bb3b84ae0608956dfb5824689
次のように変換されます:
_Hello_session=<encrypted a=b>--<digital signature>
Cookieはサーバーによって設定され、クライアント側に保持されます。ページをリクエストするたびに、ブラウザーは設定されたCookieをサーバーに再送信します。
悪人がa=b
文字列を理解するのを防ぐために、それは暗号化です。
悪意のある人々がクッキーを改ざんするのを防ぐために、デジタル署名が使用されます。
どちらの場合も、secret_key_base値が使用されます(a = bを暗号化/復号化し、デジタル署名を検証するため)。