A VPN csatlakozott, de a vegyes tartalom még mindig blokkolva van: mit kell javítani

Az oldal fele megjelenik, egy stíluslap szürkén áll a Hálózat panelen, a VPN kliens pedig továbbra is egészséges alagutat jelent. Mindhárom megfigyelés egyszerre igaz, mert a böngésző az oldal által indított kérést ítélte meg, és az alagútnak nem volt szava ebben az ítéletben. Az ügyet döntés zárja le, nem beállítás: javítani a hivatkozást, a gazdagép tulajdonosához eszkalálni, vagy elhagyni a függőséget. Mindegyik lehetőségnek van olcsó próbája, a rossz kiválasztása pedig egy támogatási ciklusba kerül.

Miért nem tudja az alagút lefedni az alerőforrást

A vegyes tartalom HTTP-n át alerőforrást kérő HTTPS-dokumentummal kezdődik. Minden URL a saját sémája szerint ítéltetik meg, ezért a szülő dokumentum védelme soha nem terjed ki a gyermek kérésre. A böngésző alatt hozzáadott titkosítás azt változtatja meg, ami a vezetéken utazik, nem az http://-t, amit a jelölés kért.

A jelenlegi böngészők két csoportba sorolják ezeket a kéréseket, és eltérően kezelik őket. A szkriptek, stíluslapok, iframe-ek és a fetch, XMLHttpRequest vagy WebSocket hívások azonnal elutasításra kerülnek, előzetes frissítési kísérlet nélkül. A képek, a hang és a videó https:// alakra íródnak át és újra kérésre kerülnek, a betöltés pedig megszakad, ha az a biztonságos lekérés meghiúsul. A csupasz IP-címet használó gazdagépű alerőforrás-URL mentesül a frissítés alól, így az IP-gazdagépen lévő HTTP-kép blokkolva marad, ahelyett hogy csendben kijavítanák. A felosztás, beleértve a frissíthető oldalon lévő kivételt, a Mozilla vegyes tartalomról szóló útmutatójában. A Chrome hasonló elutasítást alkalmaz a biztonságos oldalról indított nem biztonságos letöltésekre, ezért egy PDF-hivatkozás meghalhat, miközben a környező oldal sértetlennek tűnik.

A szürke sor tehát annak bizonyítéka, hogy a vezérlés működik, nem annak, hogy az alagút sima szöveget engedett ki. Kezelje a sort egyetlen hivatkozásra mutató leletként, nem az egész oldalra.

Határozza meg, kié a nem biztonságos hivatkozás

Rendezze a problémás URL-t aszerint, hol keletkezik, mielőtt bármit módosítana. Az a válasz dönti el, tud-e ma javítást kiadni, a szállítónak kell-e kiadnia egyet, vagy a függőségnek el kell hagynia az oldalt. Olvassa ki a Hálózat panel Initiator oszlopából, mert a képernyőn látható jelölés gyakran futásidőben áll össze.

Ha a gazdagép már a 443-on válaszol, és csak a hivatkozás mond http-t, a javítás helyi: módosítsa a hivatkozást, ürítse az oldal gyorsítótárát, és erősítse meg, hogy a sor https lesz. Az a gazdagép, amely csak a 80-as porton figyel, szerkesztéssel nem hozható összhangba, ezért az erőforrás átköltözik, valami Ön által irányított dolog kerül elé, vagy eltűnik. A címkekezelő által beszúrt URL akkor is megjelenik, ha a saját sablonja tiszta, és ez az eset olyan jegybe tartozik, amelyhez a pontos URL és a konzol sor is mellékelve van. Azt mondani a személyzetnek, hogy engedélyezze a nem biztonságos tartalmat, nem tartozik ezek közé a lehetőségek közé, mert kikapcsolja az ellenőrzést minden oldalon, amelyet ez a böngészőprofil meglátogat.

A hivatkozást javítsa, ne a böngésző beállítását

Töltse újra a hibázó folyamatot megtartott hálózati naplóval, és szűrje a panelt a gyanús gazdagépre. A konzol megnevezi az URL-t és az utasítást, ami eldönti, hogy a kérés elutasításra vagy frissítésre került-e, mielőtt sablonhoz nyúlna.

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

Két kiegészítő vezérlést érdemes ismerni, és egyik sem helyettesíti a javítást. Egy Content-Security-Policy fejléc upgrade-insecure-requests a böngészőt arra készteti, hogy az http alerőforrás-URL-eket még az oldal elhagyása előtt átírja, ami elkapja azokat a régi hivatkozásokat, amelyeket még nem talált meg. Az átírt kérés továbbra is meghiúsul, ha a célgazdagép nem szolgál HTTPS-t, tehát a fejléc csak azt változtatja meg, melyik URL-t próbálja a böngésző. A HSTS gazdagépenként érvényes, ami azt jelenti, hogy a saját domainjén lévő házirend semmit nem tesz egy harmadik fél CDN-jéért, amely soha nem küldte a fejlécet. A sablon módosítása után ürítse az oldal gyorsítótárát, és keresse a régi gazdagépnevet a renderelt HTML-ben, mert ugyanaz az URL egy rész, egy fordítási karakterlánc vagy egy adatbázismező révén is érkezhet.

Kövesse az átirányításokat is, mert egy https://-sel induló lánc http:// helyre érkezhet, és a böngésző az utolsó ugrást ítéli meg. A második parancs -L formája kiírja Önnek azt a tényleges URL-t. Ha az utolsó ugrás tiszta http, a hivatkozás továbbra is hibás, pedig a szerkesztett hivatkozás jónak tűnt.

Erősítse meg az oldalt a konzollal és a hálózati panellel

Töltse újra kikapcsolt gyorsítótárral, és járja be újra a folyamatot, beleértve az igény szerinti tartalmat betöltő gombokat is. Az oldal első betöltése elrejti a lusta widgeteket, a térképi csempéket és a lejátszószkripteket, amelyek csak kattintás után jelennek meg. A konzolnak nem szabad vegyes tartalmú bejegyzést tartalmaznia, és minden megérintett sornak https-t kell mutatnia. Rögzítse a konzolt és a kérés sorát a jegy lezárása előtt, mert ezt az állapotot a következő telepítés után nehéz újraépíteni.

Ha az erőforrás valaki másé, négy dolgot küldjön el: a pontos URL-t, a kérés típusát, a konzol szövegét és az oldalt, ahol megjelenik. Rejtse el a munkamenet-azonosítókat mindenben, amit a jegybe illeszt. Az a jelentés, amely csak annyit mond, hogy a képek töröttek, semmit nem ad a tulajdonosnak keresni.

Az alagút tovább végzi a saját dolgát, miközben a javítás abban a hivatkozásban lakik, amely a kérést létrehozta. A telepítés után még egyszer keresse meg a gazdagépnevet a sablonban és a szállítói csomagban, és csak akkor zárja le az ügyet, ha a konzolban nem maradt blokkolt vegyes tartalmú bejegyzés.