અડધું પૃષ્ઠ રેન્ડર થાય છે, એક સ્ટાઇલશીટ નેટવર્ક પેનલમાં ભૂખરી રહે છે, અને VPN ક્લાયન્ટ હજી પણ સ્વસ્થ ટનલની જાણ કરે છે. ત્રણેય અવલોકનો એકસાથે સાચાં છે, કારણ કે બ્રાઉઝરે પૃષ્ઠે કરેલી વિનંતીનો નિર્ણય કર્યો અને તે નિર્ણયમાં ટનલનો કોઈ મત નહોતો. કેસ બંધ કરનારી વસ્તુ નિર્ણય છે, સેટિંગ નહીં: સંદર્ભ સુધારો, તેને હોસ્ટના માલિક સુધી વધારો, અથવા નિર્ભરતા છોડી દો. આમાંના દરેક વિકલ્પની સસ્તી કસોટી છે, અને ખોટો પસંદ કરવો એક સહાય ચક્ર ખર્ચે છે.

ટનલ ઉપ-સંસાધનને કેમ આવરી શકતી નથી

મિશ્ર સામગ્રીની શરૂઆત એવા HTTPS દસ્તાવેજથી થાય છે જે સાદા HTTP પર ઉપ-સંસાધન માંગે છે. દરેક URL નું મૂલ્યાંકન તેની પોતાની સ્કીમ પર થાય છે, તેથી મૂળ દસ્તાવેજનું રક્ષણ ક્યારેય સંતાન વિનંતી સુધી ફેલાતું નથી. બ્રાઉઝરની નીચે ઉમેરાયેલું એન્ક્રિપ્શન તાર પર જતી વસ્તુ બદલે છે, તે http:// નહીં જે માર્કઅપે માંગ્યું હતું.

હાલના બ્રાઉઝર આ વિનંતીઓને બે જૂથોમાં વિભાજિત કરે છે અને જુદી રીતે સંભાળે છે. સ્ક્રિપ્ટ, સ્ટાઇલશીટ, iframe અને fetch, XMLHttpRequest કે WebSocket દ્વારા કરાયેલા કૉલ સીધા નકારી કાઢવામાં આવે છે, પહેલાં કોઈ અપગ્રેડ પ્રયાસ વિના. ચિત્રો, ઑડિઓ અને વિડિઓ https:// માં ફરીથી લખાય છે અને ફરી માંગવામાં આવે છે, અને તે સુરક્ષિત પ્રાપ્તિ નિષ્ફળ જાય ત્યારે લોડિંગ છોડી દેવામાં આવે છે. જે ઉપ-સંસાધનનું હોસ્ટ નગ્ન IP સરનામું છે તે URL અપગ્રેડમાંથી મુક્ત છે, તેથી IP હોસ્ટ પરનું HTTP ચિત્ર ચૂપચાપ સુધારાવાને બદલે અવરોધિત રહે છે. આ વિભાજન, અપગ્રેડ થઈ શકે તેવી બાજુની તે મુક્તિ સહિત, અહીં દસ્તાવેજીકૃત છે: Mozilla ની મિશ્ર સામગ્રી માર્ગદર્શિકામાં. Chrome સુરક્ષિત પૃષ્ઠથી શરૂ થતા અસુરક્ષિત ડાઉનલોડ પર પણ સમાન નકાર લાગુ કરે છે, તેથી PDF લિંક મરી શકે છે જ્યારે આસપાસનું પૃષ્ઠ સાબૂત દેખાય છે.

તેથી ભૂખરી પંક્તિ નિયંત્રણ કામ કરી રહ્યું છે તેનો પુરાવો છે, ટનલે સાદું લખાણ છોડ્યું તેનો પુરાવો નહીં. પંક્તિને એક સંદર્ભ તરફ ઈશારો કરતી શોધ તરીકે ગણો, આખા પૃષ્ઠ તરફ નહીં.

અસુરક્ષિત સંદર્ભ કોનો છે તે નક્કી કરો

કંઈપણ બદલતા પહેલાં સમસ્યાવાળા URL ને તે ક્યાં બને છે તેના આધારે ગોઠવો. તે જ જવાબ નક્કી કરે છે કે તમે આજે સુધારો બહાર પાડી શકો છો, કોઈ વેન્ડર એક બહાર પાડશે, અથવા નિર્ભરતાએ પૃષ્ઠ છોડવું પડશે. તેને નેટવર્ક પેનલના Initiator સ્તંભમાં વાંચો, કારણ કે સ્ક્રીન પરનું માર્કઅપ ઘણી વાર રનટાઇમમાં જોડાય છે.

URL ક્યાંથી આવે છેતેને કોણ સુધારી શકે છેપહેલું પગલું
તમે તૈનાત કરો તે ટેમ્પલેટ અથવા આંશિકમાં કઠોર-કોડેડતમેતેને https:// સ્વરૂપથી બદલો અને પછી કેશ સાફ કરો
ટેગ મેનેજર અથવા વેન્ડર બંડલ દ્વારા દાખલ કરાયેલવેન્ડર, તમારી ટિકિટ સાથેચોક્કસ URL, વિનંતી પ્રકાર અને કન્સોલ લાઇન મોકલો
ફક્ત પોર્ટ 80 પર TLS શ્રોતા વિના પરોસવામાં આવે છેહોસ્ટનો માલિકTLS માંગો, તમારી નિયંત્રિત વસ્તુ આગળ મૂકો, અથવા તેને છોડી દો

જ્યારે હોસ્ટ પહેલેથી 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, વિનંતી પ્રકાર, કન્સોલ લખાણ અને તે પૃષ્ઠ જ્યાં તે દેખાય છે. ટિકિટમાં ચોંટાડેલ દરેક વસ્તુમાંથી સત્ર ઓળખકર્તા છુપાવો. ફક્ત ચિત્રો બગડેલાં છે એમ કહેતો અહેવાલ માલિકને શોધવા કંઈ આપતો નથી.

ટનલ પોતાનું કામ ચાલુ રાખે છે જ્યારે સુધારો વિનંતી બનાવનારા સંદર્ભમાં રહે છે. તૈનાતી પછી ટેમ્પલેટ અને વેન્ડર બંડલમાં હોસ્ટ નામ ફરી એક વાર શોધો, અને કન્સોલમાં કોઈ અવરોધિત મિશ્ર સામગ્રી નોંધ ન બાકી રહે ત્યારે જ કેસ બંદ કરો.

સંબંધિત લેખો