VPN जोडिएको छ तर मिश्रित सामग्री अझै अवरुद्ध छ: के सुधार्ने

आधा पृष्ठ रेन्डर हुन्छ, एउटा स्टाइलसिट नेटवर्क प्यानलमा खैरो रहन्छ, र VPN क्लाइन्टले अझै स्वस्थ सुरुङको रिपोर्ट गर्छ। तीनै अवलोकन एकै पटक सत्य छन्, किनभने ब्राउजरले पृष्ठले गरेको अनुरोधको निर्णय गर्‍यो र त्यस निर्णयमा सुरुङको कुनै मत थिएन। मुद्दा बन्द गर्ने कुरा निर्णय हो, सेटिङ होइन: सन्दर्भ सुधार्नुहोस्, त्यसलाई होस्टको मालिकसम्म पुर्‍याउनुहोस्, वा निर्भरता छोड्नुहोस्। यीमध्ये हरेक विकल्पको सस्तो परीक्षण छ, र गलत छान्नु एक सहयोग चक्र खर्च गर्छ।

सुरुङले उप-स्रोत किन ढाक्न सक्दैन

मिश्रित सामग्रीको सुरुवात सादा HTTP मा उप-स्रोत माग्ने HTTPS कागजातबाट हुन्छ। हरेक URL आफ्नै स्किममा मूल्याङ्कन हुन्छ, त्यसैले अभिभावक कागजातको सुरक्षा कहिल्यै सन्तान अनुरोधसम्म फैलिँदैन। ब्राउजरको तल थपिएको इन्क्रिप्शनले तारमा जाने कुरा बदल्छ, मार्कअपले मागेको http:// होइन।

हालका ब्राउजरले यी अनुरोधलाई दुई समूहमा बाँड्छन् र फरक तरिकाले व्यवहार गर्छन्। स्क्रिप्ट, स्टाइलसिट, iframe र fetch, XMLHttpRequest वा WebSocket मार्फत गरिएका कल सिधै अस्वीकार गरिन्छ, पहिले कुनै अपग्रेड प्रयास नगरी। तस्बिर, अडियो र भिडियो https:// मा पुनः लेखिन्छ र फेरि मागिन्छ, र त्यो सुरक्षित प्राप्ति असफल भएमा लोडिङ छोडिन्छ। जसको होस्ट नाङ्गो IP ठेगाना हो त्यस्तो उप-स्रोतको URL अपग्रेडबाट मुक्त छ, त्यसैले IP होस्टमा HTTP तस्बिर चुपचाप सुधारिनुको सट्टा अवरुद्ध रहन्छ। यो विभाजन, अपग्रेड हुन सक्ने पक्षको त्यो छुटसहित, यहाँ अभिलेख गरिएको छ: Mozilla को मिश्रित सामग्री गाइडमा। Chrome सुरक्षित पृष्ठबाट सुरु हुने असुरक्षित डाउनलोडमा पनि यस्तै अस्वीकार लागू गर्छ, त्यसैले PDF लिङ्क मर्न सक्छ जबकि वरपरको पृष्ठ सुरक्षित देखिन्छ।

त्यसैले खैरो पङ्क्ति नियन्त्रण काम गरिरहेको प्रमाण हो, सुरुङले सादा पाठ छोडेको प्रमाण होइन। पङ्क्तिलाई एउटा सन्दर्भतर्फ संकेत गर्ने भेट मान्नुहोस्, सम्पूर्ण पृष्ठतर्फ होइन।

असुरक्षित सन्दर्भ कसको हो निर्धारण गर्नुहोस्

केही बदल्नु अघि समस्या भएको URL लाई यो कहाँ बन्छ भन्ने आधारमा क्रमबद्ध गर्नुहोस्। त्यही उत्तरले तय गर्छ कि तपाईं आज सुधार जारी गर्न सक्नुहुन्छ, कुनै विक्रेताले एउटा जारी गर्नुपर्छ, वा निर्भरताले पृष्ठ छोड्नुपर्छ। यसलाई नेटवर्क प्यानलको Initiator स्तम्भमा पढ्नुहोस्, किनभने स्क्रिनको मार्कअप प्रायः रनटाइममा जोडिन्छ।

जब होस्ट पहिले नै 443 मा जवाफ दिन्छ र केवल सन्दर्भले http भन्छ, सुधार स्थानीय हो: सन्दर्भ बदल्नुहोस्, पृष्ठको क्यास खाली गर्नुहोस् र पङ्क्ति https भएको पुष्टि गर्नुहोस्। केवल पोर्ट 80 मा सुन्ने होस्टलाई सम्पादनले अनुरूप बनाउन सकिँदैन, त्यसैले स्रोत सर्छ, यसको अगाडि तपाईंको नियन्त्रणको कुरा राखिन्छ, वा यो हराउँछ। ट्याग प्रबन्धकले घुसाएको URL तपाईंको आफ्नै टेम्प्लेट सफा हुँदा पनि देखिन्छ, र त्यो मामला सही URL र कन्सोल पङ्क्ति संलग्न भएको टिकटको हो। कर्मचारीलाई असुरक्षित सामग्री अनुमति दिन भन्नु यीमध्ये कुनै विकल्प होइन, किनभने यसले त्यो ब्राउजर प्रोफाइलले भ्रमण गर्ने हरेक साइटका लागि जाँच बन्द गर्छ।

ब्राउजर सेटिङ होइन, सन्दर्भ सुधार्नुहोस्

असफल हुने प्रवाह नेटवर्क लग सुरक्षित राखेर पुनः लोड गर्नुहोस् र प्यानललाई तपाईंले शङ्का गरेको होस्टमा फिल्टर गर्नुहोस्। कन्सोलले URL र निर्देशनको नाम लिन्छ, जसले टेम्प्लेट छुनु अघि अनुरोध अस्वीकार भयो वा अपग्रेड भयो भन्ने टुङ्गो लगाउँछ।

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

दुई सहायक नियन्त्रण जान्न योग्य छन् र कुनै पनि सुधारको विकल्प होइन। Content-Security-Policy हेडर जसमा upgrade-insecure-requests ब्राउजरलाई पृष्ठ छोड्नु अघि http उप-स्रोत URL पुनः लेख्न बाध्य पार्छ, जसले तपाईंले अझै नभेटेका पुराना सन्दर्भ समात्छ। पुनः लेखिएको अनुरोध लक्ष्य होस्टले HTTPS दिँदैन भने अझै असफल हुन्छ, त्यसैले हेडरले ब्राउजरले कुन URL प्रयास गर्छ मात्र बदल्छ। HSTS हरेक होस्टमा लागू हुन्छ, अर्थात् तपाईंको आफ्नै डोमेनको नीतिले कहिल्यै यो हेडर नपठाएको तेस्रो पक्षको CDN का लागि केही गर्दैन। टेम्प्लेट बदलेपछि पृष्ठको क्यास खाली गर्नुहोस् र रेन्डर भएको HTML मा पुरानो होस्ट नाम खोज्नुहोस्, किनभने त्यही URL कुनै आंशिक, अनुवाद स्ट्रिङ वा डेटाबेस फिल्डबाट पनि आउन सक्छ।

रिडाइरेक्ट पनि ट्र्याक गर्नुहोस्, किनभने https:// बाट सुरु हुने शृंखला http:// स्थानमा झर्न सक्छ र ब्राउजरले अन्तिम उफ्रनको निर्णय गर्छ। दोस्रो कमाण्डको -L आकृति माथिको त्यो प्रभावकारी URL तपाईंका लागि छाप्छ। यदि अन्तिम उफ्रन शुद्ध http हो भने, सन्दर्भ अझै गलत छ यद्यपि तपाईंको सम्पादित लिङ्क ठीक देखिन्थ्यो।

पृष्ठको पुष्टि कन्सोल र नेटवर्क प्यानलबाट गर्नुहोस्

क्यास बन्द गरेर पुनः लोड गर्नुहोस् र प्रवाह फेरि चलाउनुहोस्, मागअनुसार सामग्री लोड गर्ने बटनसमेत। पृष्ठको पहिलो लोडिङले अल्छी विजेट, नक्साका टाइल र प्लेयर स्क्रिप्ट लुकाउँछ जो क्लिकपछि मात्र देखिन्छन्। कन्सोलमा मिश्रित सामग्रीको कुनै प्रविष्टि हुनुहुँदैन र तपाईंले छोएको हरेक पङ्क्तिले https देखाउनुपर्छ। टिकट बन्द गर्नु अघि कन्सोल र अनुरोध पङ्क्ति क्याप्चर गर्नुहोस्, किनभने अर्को तैनाथीपछि त्यो अवस्था पुनः बनाउन गाह्रो छ।

जब स्रोत अरू कसैको हो, चार कुरा पठाउनुहोस्: सही URL, अनुरोध प्रकार, कन्सोल पाठ र यो देखिने पृष्ठ। टिकटमा टाँस्ने हरेक कुराबाट सत्र पहिचानकर्ता लुकाउनुहोस्। केवल तस्बिर बिग्रिएका छन् भन्ने रिपोर्टले मालिकलाई खोज्न केही दिँदैन।

सुरुङले आफ्नो काम जारी राख्छ जबकि सुधार अनुरोध बनाएको सन्दर्भमा हुन्छ। तैनाथीपछि टेम्प्लेट र विक्रेता बन्डलमा होस्ट नाम एक पटक फेरि खोज्नुहोस्, र कन्सोलमा कुनै अवरुद्ध मिश्रित सामग्री प्रविष्टि नबाँकी भएपछि मात्र मुद्दा बन्द गर्नुहोस्।