VPN е свързан, но смесеното съдържание все още е блокирано: какво да поправите
Подредете блокирания URL според това кой го е създал, поправете референцията или я предайте на собственика на хоста, а след това потвърдете поправката в конзолата на браузъра.
Половината от страницата се изобразява, един стилов лист стои сив в панела Мрежа, а VPN клиентът все още съобщава за здрав тунел. И трите наблюдения са верни едновременно, защото браузърът прецени заявка, направена от страницата, а тунелът нямаше глас в тази преценка. Случая затваря решение, а не настройка: поправете референцията, ескалирайте я към този, който притежава хоста, или се откажете от зависимостта. Всяка от тези опции има евтин тест, а изборът на грешната струва един цикъл поддръжка.
Защо тунелът не може да покрие подресурс
Смесеното съдържание започва с HTTPS документ, който иска подресурс по обикновен HTTP. Всеки URL се преценява по собствената си схема, затова защитата на родителския документ никога не се разпростира върху дъщерна заявка. Криптирането, добавено под браузъра, променя какво пътува по кабела, а не http://, което е поискала разметката.
Съвременните браузъри разделят тези заявки в две групи и се отнасят с тях различно. Скриптове, стилови листове, iframe и извиквания чрез fetch, XMLHttpRequest или WebSocket се отхвърлят веднага, без предварителен опит за надграждане. Изображения, аудио и видео се пренаписват на https:// и се заявяват отново, а зареждането се прекъсва, когато това сигурно извличане се провали. URL на подресурс, чийто хост е гол IP адрес, е изключен от надграждане, затова HTTP изображение на IP хост остава блокирано, вместо да бъде тихо поправено. Това разделение, включително изключението от надградимата страна, е документирано в ръководството на 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 кара браузъра да пренапише URL на подресурси http, преди да напуснат страницата, което улавя стари референции, които още не сте намерили. Пренаписаната заявка все още се проваля, когато целевият хост не обслужва HTTPS, затова заглавката променя само кой URL опитва браузърът. HSTS важи за отделен хост, което означава, че политика на вашия домейн не прави нищо за CDN на трета страна, който никога не е изпращал заглавката. След промяна на шаблона изчистете кеша на страницата и потърсете старото име на хост в изобразения HTML, защото същият URL може да дойде и през част, низ за превод или поле в базата данни.
Следете и пренасочванията, защото верига, започваща с https://, може да попадне на адрес http:// и браузърът преценява последния скок. Формата -L на втората команда по-горе отпечатва този ефективен URL вместо вас. Ако последният скок е чист http, референцията все още е грешна, макар редактираната от вас връзка да изглеждаше добре.
Потвърдете страницата с конзолата и панела за мрежа
Презаредете с изключен кеш и преминете потока отново, включително бутоните, които зареждат съдържание при поискване. Първото зареждане на страница скрива мързеливи джаджи, плочки на карта и скриптове на плейъра, които се появяват само след клик. Конзолата не бива да съдържа записи за смесено съдържание и всеки ред, който сте докоснали, трябва да показва https. Заснемете конзолата и реда на заявката, преди да затворите тикета, защото това състояние е трудно за възстановяване след следващото разгръщане.
Когато ресурсът принадлежи на някой друг, изпратете четири неща: точния URL, типа заявка, текста от конзолата и страницата, където се появява. Скрийте идентификаторите на сесията във всичко, което поставяте в тикет. Доклад, който само казва, че изображенията са счупени, не дава на собственика нищо за търсене.
Тунелът продължава да върши своята работа, докато поправката лежи в референцията, създала заявката. След разгръщането потърсете още веднъж името на хоста в шаблона и пакета на доставчика и затворете случая едва когато в конзолата не остане нито един блокиран запис за смесено съдържание.