VPN पछाडिको मिश्रित सामग्री: स्रोत ठीक गर्नुहोस्, सुरुङ होइन

HTTP मार्फत स्क्रिप्ट लोड गर्ने HTTPS पृष्ठले दुई फरक सुरक्षा तहसहित दुई अनुरोध गर्छ, र ताल्चाले पहिलोको मात्र वर्णन गर्छ। सुरुङले यो बदल्दैन, किनकि यसले वाहकलाई जोगाउँछ, स्रोतको आफ्नै योजनालाई होइन। तपाईंले ठेगाना पट्टीको सट्टा कन्सोल पढ्नुभयो भने ब्राउजरले कुन अनुरोध असफल भयो भनी पहिल्यै बताइरहेको छ। तीन जाँचले तपाईंलाई आधा काम गर्ने पृष्ठबाट वास्तविक मर्मतसम्म पुर्याउँछ।

अनुरोध पढ्नुहोस्, ठेगाना पट्टी होइन

HTTPS बाट ल्याइएको कागजातले साधारण HTTP मार्फत स्क्रिप्ट, स्टाइलसिट, फन्ट वा फ्रेमलाई सन्दर्भ दिन सक्छ। त्यो सन्दर्भ छुट्टै अनुरोध हो, र ब्राउजर त्यसैको गुनासो गर्छ। मुख्य कागजातको सुरक्षा त्यसमा फर्केर जाँदैन, र दुवै प्रवाह बोक्ने सुरुङले कुनै पनि योजना बदल्दैन। त्यसैले पृष्ठ एकै समयमा साँच्चै सुरक्षित र साँच्चै बिग्रिएको हुन सक्छ।

स्रोतलाई केवल समावेश गरिएको फाइल भन्नुले यसको प्रतिस्थापनलाई हानिरहित बनाउँदैन।

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

कुन स्रोत अवरुद्ध हुन्छन् र कुन उन्नत हुन्छन् जान्नुहोस्

ब्राउजरहरूले हरेक प्रकारको स्रोतलाई एउटै तरिकाले व्यवहार गर्दैनन्। मिश्रित सामग्री सम्बन्धी निर्देशिका HTTPS मा उन्नत गरिने अनुरोधहरूलाई पूर्ण रूपमा अवरुद्ध गरिने अनुरोधहरूबाट अलग गर्छ, जसमा स्क्रिप्ट, स्टाइलसिट र प्रोग्रामीय अनुरोधहरू अवरुद्ध पक्षमा हुन्छन्, जबकि चित्र र मिडियालाई यसको सट्टा उन्नत वा चिन्हित गर्न सकिन्छ।

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

अवरुद्ध विजेट सुरुङ असफल भएको प्रमाण होइन। यो ब्राउजरले आफ्नो काम गरेको प्रमाण हो।

सन्दर्भलाई यसको स्रोतमै सच्याउनुहोस्

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

त्यसपछि स्रोत साँच्चै वैध पहिचानसहित HTTPS मार्फत उपलब्ध गराइएको छ भनी पुष्टि गर्नुहोस्, किनकि योजना परिवर्तनले त्यहाँ कहिल्यै प्रकाशित नभएको सेवा सिर्जना गर्न सक्दैन।

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

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

प्रयोगकर्ताले पृष्ठ छोएझैं फेरि परीक्षण गर्नुहोस्

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

सुरुङको आफ्नै काम अझै छ, र त्यो काम नेटवर्क पहुँच हो, पृष्ठको अखण्डता होइन।

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