seguito la documentazione Engine Yard a https://support.cloud.engineyard.com/entries/21715452-use-elastic-load-balancing-with-engine-yard-cloudEngine Yard applicazione Rails - terminazione SSL ad un carico elastico Balancer (ELB) e passando X-Forwarded-Proto http intestazione
Got questo set up e sembrava lavorare bene permettendoci di usa SSL Terminato su ELB invece sul server. In teoria questo dovrebbe consentirci di utilizzare e più certificati SSL in un singolo ambiente.
Questa configurazione indica che il traffico tra il browser e il bilanciamento del carico ELB è SSL, ma il traffico verso l'interno dal server ELB ai server delle applicazioni viene decifrato. Questo ci ha causato un problema con l'applicazione forzata SSL di rails 3.2.8 - reindirizza ogni richiesta decrittografata al suo equivalente https, che invia di nuovo una richiesta decrittografata dal servizio di bilanciamento del carico al server dell'applicazione, causando una condizione di ciclo infinito.
Se disabilitiamo la forzatura di SSL nella nostra app dobbiamo testare ogni richiesta per vedere se proviene da una connessione SSL, se così fosse possiamo rispondere, in caso contrario, reindirizzarlo.
In base a questa nota di rilascio (http://aws.amazon.com/releasenotes/7778622769836370), l'ELB passerà l'intestazione X-Forwarded-Proto contenente 'https' quando il traffico viene passato da una connessione https.
In primo luogo non è presente alcuna intestazione denominata "X-Forwarded-Proto" nella richiesta su Engine Yard. 'HTTP_X-FORWARDED_PROTO' esiste, ma contiene sempre 'http' anche quando il traffico viene inviato su SSL all'ELB.
Qualcuno può offrire qualche idea in questo o idee per una soluzione alternativa? Ho provato il supporto EY senza troppa fortuna finora.
Se si contatta EngineYard, è possibile abilitare il flag di funzionalità stunnel per la propria app, che manterrà l'x-proto-forward in posizione e non lo eliminerà. –