Приложение Engine Yard Rails - Завершение SSL на Elastic Load Balancer (ELB) и передача http-заголовка X-Forwarded-Proto
Следуйте документам Engine Yard по адресу https://support.cloud.engineyard.com/entries/21715452-use-elastic-load-balancing-with-engine-yard-cloud
Он был настроен и, по-видимому, работал хорошо, что позволило нам использовать SSL-терминацию на ELB, а не на сервере. Теоретически это должно позволить нам использовать несколько сертификатов SSL в одной среде.
Эта настройка означает, что трафик между браузером и балансировщиком нагрузки ELB является SSL, но входящий трафик от ELB к серверам приложений расшифровывается. Это вызвало у нас проблему с приложением rails 3.2.8, заставляющим SSL - оно перенаправляет каждый расшифрованный запрос обратно в его https-эквивалент, который снова отправляет дешифрованный запрос с балансировщика нагрузки на сервер приложений, вызывая состояние бесконечного цикла.
Если мы отключим принудительное использование SSL в нашем приложении, нам нужно протестировать каждый запрос, чтобы увидеть, пришел ли он из соединения SSL, и если мы это сделали, мы можем ответить, если нет, перенаправить его.
Согласно этой заметке о выпуске ( http://aws.amazon.com/releasenotes/7778622769836370) ELB будет передавать заголовок X-Forwarded-Proto, содержащий "https", когда трафик передается из соединения https.
Во-первых, в запросе на Engine Yard нет заголовка с именем "X-Forwarded-Proto". HTTP_X-FORWARDED_PROTO существует, но он всегда содержит http, даже если трафик передается по протоколу SSL на ELB.
Может ли кто-нибудь предложить какое-либо понимание этого или идеи для обхода? До сих пор я пробовал поддержку EY без особой удачи.
1 ответ
Вы можете проверить заголовок X-Forwarded-Port, который равен 443, если запрос пришел к балансировщику нагрузки через ssl. Это было бы HTTP_X_FORWARDED_PORT в стойке окр.
В качестве обходного пути мы используем этот измененный гем rack-ssl в нашем приложении Engine Yard Rails.