Более быстрый / более масштабируемый подход к Twitter OAuth Dance в Rails?

Question

Я использую приложение Rails в стеке Heroku (в комплекте с Memcached, асинхронными рабочими DJ, постоянным хранилищем MongoDB).

В настоящее время мы используем Twitter Oauth в качестве единственной опции аутентификации на нашем сайте.(Мы планируем перейти на FB connect, OpenID и / или Email / пароль в конечном итоге.)

Приложения Ruby / Rails, как вы, вероятно, знаете, не поддерживают параллелизм из коробки.В Heroku вы можете раскрутить дополнительные экземпляры приложений (dynos), что увеличит ваш параллелизм (возможность параллелизма = количество dynos), но каждый стоит 36 $ / месяц.

В общем, это не было проблемой, потому что средний запрос на сайте занимает <100 мс.</p>

ИСКЛЮЧИТЬ для Twitter OAuth.Связанные с OAuth запросы в Twitter занимают в среднем около 3500 мсек.

Таким образом, когда кто-то входит в систему всего экземпляра приложения, его задерживают на 3-4 секунды.

Есть ли приличный способ смягчить это?Было бы странно помещать эти действия в асинхронных диджеев?Это может сделать вход немного медленнее, но, по крайней мере, если сразу несколько людей входят в систему и / или Twitter действительно работает медленно, эти процессы не влияют на остальную часть приложения / другие веб-запросы?

Есть еще идеи?

Answer 1

Я бы сказал, что этот совет теперь отменен.Я бы посоветовал вам использовать OmniAuth вместо этого, возможно, с Devise, если вам также требуется нормальная аутентификация.

OmniAuth - это предложенное Rack-приложение, и вы в основном получаете все "большие" OAuth-провайдеры, работающие сразу.

Есть 2 специфичных для OmniAuth RailsCasts, которые проведут вас именно через то, что нужно:1005 * OmniAuth часть 1 и OmniAuth часть 2

Answer 2

Вы можете вставить oAuth в приложение промежуточного программного обеспечения для стойки - тогда по крайней мере только стоечное приложение будет помещено в буфер вместо целого стека рельсов. Это должно сделать это немного быстрее (хотя это все равно займет экземпляр).

При этом нет никаких причин, по которым вы не можете поместить аутентификацию в его собственное приложение, особенно если оно находится в одном домене (поэтому любые куки-файлы аутентификации по-прежнему локальны для домена). Хотя вы должны быть очень осторожны с вопросами безопасности - например, атаками «человек посередине» и т. Д. Лучше, если кто-то уже сделал работу / исправление ошибок для вас:)

Вы даже можете иметь приложение для аутентификации в независимом домене приложений, если используете rubyCAS: http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html