Engine Yard Rails-Anwendung - Abschluss SSL auf einem Elastic Load Balancer (ELB) und vorbei X-Forwarded-Proto HTTP-Header

Question

Gefolgt die Engine Yard docs bei https://support.cloud.engineyard.com/entries/21715452-use-elastic-load-balancing-with-engine-yard-cloud

erhielt diese Einrichtung und schien gut zu arbeiten ermöglicht es uns, Verwenden Sie SSL Terminated am ELB statt am Server. Theoretisch sollte es uns ermöglichen, mehrere SSL-Zertifikate in einer einzigen Umgebung zu verwenden.

Diese Konfiguration bedeutet, dass der Datenverkehr zwischen dem Browser und dem ELB Load Balancer SSL ist, der weitere Datenverkehr vom ELB zu den Anwendungsservern jedoch entschlüsselt wird. Dies verursachte uns ein Problem mit unserer Anwendung rails 3.2.8, die SSL erzwingt - es leitet jede entschlüsselte Anfrage zurück zu ihrem https-Äquivalent, das eine entschlüsselte Anfrage von dem Load-Balancer erneut an den Anwendungsserver sendet, was eine Endlosschleife verursacht.

Wenn wir die Erzwingung von SSL in unserer App deaktivieren, müssen wir jede Anfrage testen, um zu sehen, ob sie von einer SSL-Verbindung stammt. Wenn ja, können wir sie umleiten, wenn nicht.

Gemäß dieser Release-Information (http://aws.amazon.com/releasenotes/7778622769836370) wird der ELB den Header X-Forwarded-Proto mit 'https' übergeben, wenn der Datenverkehr von einer https-Verbindung weitergeleitet wird.

Erstens gibt es keinen Header namens "X-Forwarded-Proto" in der Anfrage auf Engine Yard. "HTTP_X-FORWARDED_PROTO" existiert zwar, enthält aber immer "http", auch wenn der Datenverkehr über SSL an den ELB gesendet wird.

Kann mir jemand Einblick in diese oder Ideen für einen Workaround geben? Ich habe die EY-Unterstützung bisher ohne viel Glück ausprobiert.

Answer 1

Sie können nach dem X-Forwarded-Port-Header suchen, der 443 ist, wenn die Anforderung über SSL zum Load Balancer kam. Das wäre HTTP_X_FORWARDED_PORT im Rack env.

Wir verwenden this modified rack-ssl Juwel in unserer Engine Yard Rails App als Workaround.