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, тып запыту, тэкст кансолі і старонку, дзе ён з'яўляецца. Схавайце ідэнтыфікатары сеансу ва ўсім, што ўстаўляеце ў тыкет. Справаздача, якая толькі кажа, што выявы зламаныя, не дае ўладальніку нічога для пошуку.
Тунель далей робіць сваю працу, пакуль выпраўленне ляжыць у спасылцы, што стварыла запыт. Пасля разгортвання яшчэ раз пашукайце імя хоста ў шаблоне і пакеце пастаўшчыка і закрывайце справу толькі тады, калі ў кансолі не застанецца ніводнага заблакаванага запісу пра змешаны змест.