在 Rails 中实现 Twitter OAuth Dance 的更快/更可扩展的方法？答案

【问题标题】：A Faster / More Scalable Approach to Twitter OAuth Dance in Rails?在 Rails 中实现 Twitter OAuth Dance 的更快/更可扩展的方法？
【发布时间】：2011-03-26 09:54:14
【问题描述】：

我正在 Heroku Stack 上运行一个 Rails 应用程序（包括 Memcached、DJ 异步工作者、MongoDB 持久存储）。

目前，我们使用 Twitter Oauth 作为我们网站上的唯一身份验证选项。（我们计划最终扩展到 FB 连接、OpenID 和/或电子邮件/密码）。

您可能知道，Ruby/Rails 应用程序不支持开箱即用的并发。在 Heroku 上，您可以启动额外的应用程序实例 (dynos)，这会增加您的并发性（并发能力 = dynos 的数量），但每个实例的成本为 36 美元/月。

一般来说，这不是问题，因为网站上的平均请求需要

Twitter OAuth 除外。对 Twitter 的 OAuth 相关请求平均需要大约 3,500 毫秒。

所以基本上，当任何人登录整个应用程序实例时，都会延迟 3-4 秒。

有什么体面的方法可以缓解这种情况吗？将这些动作放在异步 DJ 工作者中会不会很奇怪？它可能会使登录速度变慢，但至少如果一群人同时登录和/或 Twitter 非常慢，这些过程不会影响应用程序的其余部分/其他网络请求？

还有其他想法吗？

【问题讨论】：

标签： ruby-on-rails ruby oauth heroku delayed-job

【解决方案1】：

我会说这个建议现在已被取代。我建议您改用 OmniAuth，如果您也需要正常的身份验证，也可以使用 Devise。

OmniAuth 是建议的 Rack 应用程序，您基本上可以让所有“大型”OAuth 提供商一举成名。

有 2 个 OmniAuth 特定的 RailsCasts 可以准确地引导您完成所需的内容：OmniAuth Part 1 和 OmniAuth Part 2

【讨论】：

【解决方案2】：

您可以将 oAuth 推送到机架中间件应用程序中 - 然后至少只有一个机架应用程序被假脱机，而不是整个 rails 堆栈。这应该让它更快一点（尽管它仍然会占用一个实例）。

话虽如此，您没有理由不能将身份验证放入它自己的应用程序中，特别是如果它们都在同一个域中（因此任何身份验证 cookie 仍然是域的本地）。尽管您必须非常小心安全问题 - 例如中间人攻击等。如果有人已经为您完成了工作/错误修复，那就更好了:)

如果你使用 rubyCAS，你甚至可以在独立的应用域上拥有一个身份验证应用：http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html

【讨论】：