गुजर https://support.cloud.engineyard.com/entries/21715452-use-elastic-load-balancing-with-engine-yard-cloudइंजन यार्ड रेल एप्लिकेशन - एक लचीला लोड बैलेंसर (ईएलबी) पर एसएसएल समाप्त और X-Forwarded-आद्य HTTP हेडर
इस सेट अप समझे पर इंजन यार्ड डॉक्स बाद और करने के लिए अच्छी तरह से काम कर हमें अनुमति देने के लिए दिखाई दिया सर्वर पर ईएलबी पर समाप्त एसएसएल का उपयोग करें। सिद्धांत रूप में हमें एक ही वातावरण में उपयोग करने और एकाधिक एसएसएल कर्टों की अनुमति देनी चाहिए।
इस सेटअप का अर्थ है ब्राउज़र और ईएलबी लोड बैलेंसर के बीच यातायात एसएसएल है, लेकिन ईएलबी से आगे के ट्रैफिक को सर्वर सर्वर पर डिक्रिप्ट किया गया है। इसने हमें एसएसएल को मजबूर करने के लिए हमारे रेल 3.2.8 आवेदन के साथ एक समस्या उत्पन्न की - यह प्रत्येक डिक्रिप्ट अनुरोध को उसके https समकक्ष पर वापस रीडायरेक्ट करता है, जो लोड बैलेंसर से फिर से एप्लिकेशन सर्वर पर एक डिक्रिप्ट अनुरोध भेजता है, जिससे अनंत लूप स्थिति होती है।
अगर हम अपने ऐप में एसएसएल की मजबूती को अक्षम करते हैं तो हमें यह देखने के लिए प्रत्येक अनुरोध का परीक्षण करना होगा कि यह एसएसएल कनेक्शन से आया है, अगर ऐसा होता है तो हम जवाब दे सकते हैं, अगर नहीं, तो इसे पुनर्निर्देशित करें।
इस रिलीज नोट के अनुसार (http://aws.amazon.com/releasenotes/7778622769836370) ईएलबी एक्स-फोरवर्डेड-प्रोटो हेडर को 'https' से गुजरता है जब ट्रैफिक को https कनेक्शन से पारित किया जाता है।
सबसे पहले इंजन यार्ड पर अनुरोध में 'एक्स-फॉरवर्डेड-प्रोटो' नामक कोई हेडर नहीं है। 'HTTP_X-FORWARDED_PROTO' मौजूद है, लेकिन जब भी एसएसएल पर ईएलबी पर ट्रैफिक भेजा जाता है तब भी इसमें 'http' होता है।
क्या कोई इस काम या विचार के लिए विचारों में कोई अंतर्दृष्टि प्रदान कर सकता है? मैंने अभी तक बहुत भाग्य के बिना ईवाई समर्थन की कोशिश की है।
यदि आप इंजनयार्ड से संपर्क करते हैं, तो वे आपके ऐप के लिए स्टनल फीचर फ्लैग को सक्षम कर सकते हैं, जो एक्स-प्रोटो-फॉरवर्ड को जगह में रखेगा और इसे बाहर नहीं करेगा। –