有关于如何在网络上管理API令牌的一些问题，但我看到很多人只是重复他们在其他地方阅读的内容，而且他们经常不喜欢很有意义......
我想知道你们是如何处理所有这些API代币等的。
这是我到目前为止使用3种不同的宝石阅读的内容
引入Rails 4.1，应该成为存储秘密的惯例
是（显然不是？）意味着推送到存储库。但是我经常看到使用环境变量进行生产的示例
development:
secret_key_base: super_long_secret_key_for_development
...
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
...
此时有人问“我们为什么要使用ENV进行生产？”这是一个合法的问题IMO。但后来有人回答“我们不希望生产令牌在应用程序中被硬编码”（也许只是我，但是哼哼 SECRETS .yml，这个名字听起来像你不想要的文件提交权利？），最终没有人真正回答问题
但我仍然设法找到了这个和那个：
优点：
capistrano-secrets gem和cap [stage] setup轻松部署（并且它只能部署舞台机密）缺点：
Rails.application.secrets.xxx 只需在启动时由Rails读取的根目录下定义.env文件
使用capistrano-env和capistrano
赞成
CON外
某种混合秘密/ ENV。考虑到12个因素/ Rails / Heroku，但最终看起来并不比其他人好......
从上面和其余部分我没有写，看起来像secretts.yml将是一个伟大的赢家，如果这些秘密被放入ENV而不是（并且我觉得每次写Rails.Application.secrets都很懒惰）。
所以，假设我启动了一个非常新的Rails应用程序，并且还根据您的经验。你会选择哪一个？
（我的特定堆栈使用AWS + Capistrano，没有Heroku）
答案 0 :(得分：0)
我个人认为“正确”的方法取决于您的环境。
在我的情况下，我有由IT管理的服务器，我无法访问vhost或其他任何东西来轻松设置环境变量。因此，我提交了一个不包含生产节的secrets.yml文件，然后设置Capistrano将此文件添加到shared_files。在每台服务器上，我添加文件。
如果我可以轻松访问vhost，并且我使用Puppet，Chef，Ansible或类似的方式管理服务器虚拟主机，我会使用环境变量方法，如默认的secrets.yml文件。
您与AWS的案例似乎是后者。最终，任何一种选择都可以。提交没有生产节的secrets.yml文件几乎没有什么缺点。
答案 1 :(得分：0)
首先，所有三种方法都可以兼容12因子。如果您通过ENV变量传递配置值，而不是首先将一个文件复制到服务器，它是兼容的。
我的想法是这些解决方案中的每一个：
开发人员被迫采用12因子，要么在生产服务器上手动设置，要么在本地计算机上有另一个文件，然后每次在部署期间将其作为ENV传递。 （不知道.env.production，它可能会处理这个问题）
（我认为你在CON＃2和＃3中所说的与secret.yml解决方案相反）
你提到的访问者也很长。
它不鼓励12因素和was not originally designed for production env anyways。您可以编写代码以在部署期间将其值作为ENV传递给生产（使其与12因子兼容），或者将Setting.dig(:fb,:api)文件复制到生产服务器。
它还会强制您使用平键：值配置。没有嵌套。
虽然它使用YAML，但它不允许嵌套哈希。
它是12因子兼容的，例如它包含将配置传输到heroku的代码。
我写了一个gem，其中的设置存储在gitignored YAML文件中。允许嵌套。访问某些值时，请执行setTimeout(function(){
$(".like-post").replaceWith('<div class="newClass">Hello!</div>');
}, 1000);。
它提供了12因素应用程序部署的机制，通过将整个YAML文件序列化为字符串并将其作为ENV传递给生产。
我不再需要区分秘密配置和非秘密配置。它们默认在一个地方和秘密。在使用易于命名空间的YAML文件时，我从12因素应用程序中受益。