我刚刚从5.1升级到5.2,我对这种存储机密的“更好”方法感到困惑......
也许我不理解,但似乎现在开发和制作已经'合并'为单SECRET_KEY_BASE
以及master.key
......这是正确的吗?
如果没有,我如何在开发中使用单独的主密钥和SECRET_KEY_BASE
?
如果我让开发人员帮助我并且我不希望他们知道我在制作中使用的主密钥(或秘密)怎么办?
答案 0 :(得分:7)
Rails 5.2
改变了这一点。对于开发和测试enivoronments,secret_key_base是自动生成的,因此您可以将其从secrets.yml
或您设置的任何位置删除。
对于生产,您可以通过运行rails credentials:edit
生成和编辑凭据文件。这也将在config/master.key
中创建主密钥,该密钥仅用于加密和解密此文件。将其添加到gitignore
,以便不与其他任何人共享,这应该与其他开发人员共享。
如果所有这些听起来有点单调乏味,那么你可以忽略它并在ENV中提供secret_key_base。 Rails会在投诉前检查它是否存在于ENV["SECRET_KEY_BASE"]
。
答案 1 :(得分:5)
有两种访问secret_key_base的方法:
默认情况下,Rails 5采用第一种方式。
您可以通过 } else {
L_rc = call_bind(m_socket_id,
/* UDP Does not need to bind first */
if(m_type != E_SOCKET_UDP_MODE) {
L_rc = call_bind(m_socket_id,
(sockaddr *)(void *)&(m_remote_addr_info->m_addr_src),
SOCKADDR_IN_SIZE(&(m_remote_addr_info->m_addr_src)));
} else {
L_rc = 0;
}
来更改Rails.application.credentials.secret_key_base
。对于所有其他环境,请记住将环境变量rails credentials:edit
设置为与RAILS_MASTER_KEY
相同的内容。 config/master.key
默认是git忽略的。这种方式对所有环境都使用相同的密钥。如果要使用其他键,则需要自己控制名称空间。
如果您喜欢第二种方式master.key
。您需要创建Rails.application.secrets.secret_key_base
:
config/secrets.yml
请记住在生产环境中设置环境变量development:
secret_key_base: ...
test:
secret_key_base: ...
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
。
如果SECRET_KEY_BASE
文件足够机密,则可以将config/secrets.yml
更改为纯文本。
<%= ENV["SECRET_KEY_BASE"] %>
可以为您生成一个随机密钥。
由于简单,我更喜欢第二种方法(旧方法)。
答案 2 :(得分:1)
当我不想与我的朋友开发人员共享生产master.key时,就使用了这个gem,我认为这与OP的用途完全相同。
https://github.com/sinsoku/rails-env-credentials
您可以为每个环境都拥有一个主密钥,如下所示,因此您可以自行决定要与哪些开发者/部署者共享哪个密钥。
config/credentials-development.yml.enc
config/credentials-test.yml.enc
config/credentials.yml.enc
master-development.key
master-test.key
master.key
每次运行以下命令时都会生成每个密钥:
rails env_credentials:edit -e开发
如果您从一种master.key设置切换到此设置,则可能遇到的一个错误将与config / database.yml有关,在该配置中,Rails会尝试评估所有环境信息,而不管您所处的环境如何。 (即使您将它们注释掉,Rails仍会尝试评估erb部分。)