HTTPS अनुरोध में, Request.IsSecureConnection वापसी झूठी

मेरे पास https (SSL) में एक एएसपीनेट एप्लिकेशन काम कर रहा है। यह मेरे स्थानीय कंप्यूटर और अमेज़ॅन एडब्ल्यूएस (उत्पादन पर्यावरण) में अच्छी तरह से काम कर रहा है।HTTPS अनुरोध में, Request.IsSecureConnection वापसी झूठी

लेकिन जब मैं इस एप्लिकेशन को कार्यालय में (परीक्षण के लिए) होस्ट करता हूं तो कुछ अजीब चीजें होती हैं।

मैं https ब्राउज़र में और लॉक संकेत देख सकते हैं।
फ़िडलर भी दिखा रहा है कि उत्पादन एन्क्रिप्टेड और बंदरगाह से पता चलता है 443.
लेकिन HttpContext.Current.Request.IsSecureConnection रिटर्न झूठी
और HttpContext.Current.Request.Url.Scheme रिटर्न http।

कार्यालय में हम जुनिपर एसएसजी फ़ायरवॉल और TMG 2010 (Forefront ख़तरा प्रबंधन गेटवे 2010) का उपयोग कर रहे हैं। तो सर्वर जूनियर और टीएमजी 2010 के माध्यम से अनुरोध प्राप्त करते हैं। अग्रिम धन्यवाद।

स्रोत

2012-10-04 Jomy John

लागत मुझे लगता है कि SSL प्रमाणपत्र TMG गेटवे पर स्थापित है और जब यह वास्तविक वेब सर्वर से गुजर रहा है कि इस प्रवेश द्वार बस मानक HTTP अनुरोध करने के लिए पुनर्लेखन है कम करने के लिए। इसलिए जब तक अनुरोध आईआईएस और आपके वेब एप्लिकेशन को हिट करता है, यह एक मानक सादा HTTP अनुरोध है। जांच करें कि कौन बंदरगाह सुरक्षित कनेक्शन के लिए प्रयोग किया जाता है आम तौर पर यह 443

स्रोत

2012-10-04 11:04:21

एसएमएल प्रमाणपत्र टीएमजी –

में स्थापित है ठीक है, तो यह व्यवहार को बताता है। टीएमजी वेब सर्वर पर जाने से पहले अनुरोध को फिर से लिख रहा है। –

@JomyJohn अगर एसएसएल * टीएमजी पर * समाप्त हो जाता है, तो एएसपी.नेट सही है: एएसपी.NET को प्राप्त अनुरोध https –

खैर जाँच करने के लिए एक और तरीका है बंदरगाह की जाँच करने के

if(context.Request.Url.Port == 443)

नोट है वातावरण। मैं लोड-बैलेंसर को एसएसएल अनुरोध को सर्वर से सीधे अनुमति देने के लिए कोई रास्ता नहीं देख सका। इसके बजाय यह हमेशा लोड-बैलेंसर पर एसएसएल को समाप्त कर रहा था और सादे http को सर्वर पर वापस भेज रहा था।

मैं इस दस्तावेज़ पाया: Elastic Load Balancing Concepts - X-Forwarded Headers।

अनिवार्य रूप से लोड-बैलेंसर बैक-एंड सर्वर पर अग्रेषित करने से पहले प्रत्येक अनुरोध में अतिरिक्त HTTP Headers इंजेक्ट करता है। सबसे प्रासंगिक एक X-Forwarded-Proto है जो क्लाइंट के ब्राउज़र से लोड-बैलेंसर में कनेक्ट करने के लिए प्रयुक्त प्रोटोकॉल को ट्रैक करता है। इस तरह की जांच की जा सकती है:

var loadbalancerReceivedSSLRequest = string.Equals(Request.Headers["X-Forwarded-Proto"], "https"); 
var serverReceivedSSLRequest = Request.IsSecureConnection; 

if (loadbalancerReceivedSSLRequest || serverReceivedSSLRequest) 
{ 
    // SSL in use. 
} 
else 
{ 
    // SSL not in use. 
}

स्रोत

2014-03-30 09:13:38

यह काम नहीं करता है क्योंकि वेब सर्वर अभी भी पोर्ट 80 के रूप में अनुरोध देखता है। – Aki

@Aki आप सही हो सकते हैं, लेकिन विवरण में "जॉमी "उल्लेख किया कि फिडलर पर वह पोर्ट 443 देखता है .... –

मुझे लगता है कि ऐसा इसलिए है क्योंकि फिडलर क्लाइंट और लोड बैलेंसर के बीच अनुरोध दिखाएगा जो एन्क्रिप्टेड (पोर्ट 443) है। लेकिन लोड बैलेंसर और वेब सर्वर के बीच अनुरोध पोर्ट 80 दिखाएगा और यही वह है जो एएसपी.नेट देखता है। – Aki

यह अमेज़न के लचीला बीनस्टॉक करने की तैनाती के बाद मेरे ऊपर फिसल गया है:

स्रोत

2014-12-17 13:05:41 sheikhjabootie

संबंधित संसाधन: http://www.bugdebugzone.com/2013/12/identifying-https-or-ssl-connection-in.html –

HTTPS अनुरोध में, Request.IsSecureConnection वापसी झूठी

उत्तर

संबंधित मुद्दे