Nakakonekta ang VPN pero naka-block pa rin ang mixed content: ano ang aayusin
Isaayos ang naka-block na URL ayon sa gumawa nito, ayusin ang reference o ibigay ito sa may-ari ng host, pagkatapos ay kumpirmahin ang pag-aayos mula sa console ng browser.
Kalahati ng pahina ang nire-render, isang stylesheet ang naka-gray sa panel ng Network, at nag-uulat pa rin ang VPN client ng malusog na tunnel. Totoo ang tatlong obserbasyon nang sabay, dahil hinatulan ng browser ang isang request na ginawa ng pahina at walang boses ang tunnel sa hatol na iyon. Ang nagtatapos sa kaso ay isang desisyon, hindi isang setting: ayusin ang reference, i-escalate ito sa may-ari ng host, o bitawan ang dependency. Bawat isa sa mga opsiyon ay may murang pagsubok, at ang pagpili ng mali ay kumakain ng isang siklo ng suporta.
Bakit hindi kayang saklawin ng tunnel ang isang subresource
Nagsisimula ang mixed content sa isang dokumentong HTTPS na humihingi ng subresource sa simpleng HTTP. Bawat URL ay hinahatulan ayon sa sarili nitong scheme, kaya hindi kailanman umaabot ang proteksiyon ng magulang na dokumento sa request ng anak. Binabago ng encryption na idinagdag sa ilalim ng browser ang dumadaan sa kawad, hindi ang http:// na hiniling ng markup.
Hinahati ng mga kasalukuyang browser ang mga request na ito sa dalawang grupo at iba ang trato sa kanila. Ang mga script, stylesheet, iframe at tawag sa fetch, XMLHttpRequest o WebSocket ay tinatanggihan agad, nang walang pagtatangkang i-upgrade muna. Ang mga larawan, audio at video ay isinusulat muli sa https:// at hinihingi muli, at binibitawan ang pag-load kapag nabigo ang secure na pagkuha. Ang URL ng subresource na ang host ay hubad na IP address ay hindi saklaw ng pag-upgrade, kaya nananatiling naka-block ang isang HTTP na larawan sa host na IP sa halip na tahimik na ayusin. Ang paghahati, kasama ang pagbubukod sa panig na nai-upgrade, ay dokumentado sa gabay ng Mozilla sa mixed content. Naglalapat ang Chrome ng katulad na pagtanggi sa mga hindi secure na download na sinimulan mula sa secure na pahina, kaya maaaring mamatay ang isang PDF link habang buo ang tingin sa paligid na pahina.
Ang gray na hilera ay patunay na gumagana ang kontrol, hindi patunay na naglabas ng plaintext ang tunnel. Ituring ang hilera na isang natuklasan na tumuturo sa isang reference, hindi sa buong pahina.
Tukuyin kung kanino ang hindi secure na reference
Isaayos ang problemang URL ayon sa kung saan ito ginagawa bago baguhin ang anuman. Ang sagot na iyon ang magpapasya kung makakapaglabas ka ng pag-aayos ngayon, kung kailangang maglabas ng isa ang vendor, o kung kailangang umalis ng dependency sa pahina. Basahin ito sa column ng Initiator sa panel ng Network, dahil kadalasang binubuo sa runtime ang markup sa screen.
| Saan nagmula ang URL | Sino ang makakaayos | Unang hakbang |
|---|---|---|
| Hardcoded sa isang template o partial na ikinakabit mo | Ikaw | Palitan ito ng anyong https:// pagkatapos ay i-clear ang cache |
| Iniksyon ng tag manager o ng bundle ng vendor | Ang vendor, kasama ang iyong ticket | Ipadala ang eksaktong URL, uri ng request at linya ng console |
| Ihinahatid lamang sa port 80 nang walang TLS listener | Ang may-ari ng host | Humingi ng TLS, maglagay ng sarili mong bagay sa harap nito, o bitawan ito |
Kapag sumasagot na ang host sa 443 at ang reference lang ang nagsasabing http, lokal ang pag-aayos: palitan ang reference, i-clear ang cache ng pahina at kumpirmahin na nagiging https ang hilera. Ang host na nakikinig lamang sa port 80 ay hindi maaaring gawing sumusunod sa pamamagitan ng pag-edit, kaya lumilipat ang resource, inilalagay ang isang bagay na kontrolado mo sa harap nito, o nawawala ito. Ang URL na iniksyon ng tag manager ay patuloy na lumalabas kahit malinis ang sarili mong template, at ang kasong iyon ay nabibilang sa isang ticket na may eksaktong URL at linya ng console na nakalakip. Ang pagsasabi sa staff na payagan ang hindi secure na content ay hindi isa sa mga opsiyong ito, dahil pinapatay nito ang pagsusuri para sa bawat site na binibisita ng profile ng browser na iyon.
Ayusin ang reference, hindi ang setting ng browser
I-reload ang nabigong daloy na pinanatili ang network log at i-filter ang panel ayon sa host na pinaghihinalaan mo. Pinangalanan ng console ang URL at ang directive, na nagpapasya kung tinanggihan o ini-upgrade ang isang request bago mo hawakan ang isang template.
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.jsDalawang pantulong na kontrol ang dapat malaman, at wala sa kanila ang pumapalit sa pag-aayos. Ang header na Content-Security-Policy na may upgrade-insecure-requests ay nagpapangyaring muling isulat ng browser ang mga URL ng http subresource bago umalis sa pahina, na humuhuli sa mga lumang reference na hindi mo pa natagpuan. Nabibigo pa rin ang muling isinulat na request kapag hindi naghahatid ng HTTPS ang target na host, kaya binabago lang ng header kung aling URL ang sinusubukan ng browser. Gumagana ang HSTS kada host, ibig sabihin, walang nagagawa ang patakaran sa sarili mong domain para sa CDN ng third party na hindi kailanman nagpadala ng header. Pagkatapos ng pagbabago sa template, i-clear ang cache ng pahina at hanapin ang lumang pangalan ng host sa naka-render na HTML, dahil maaaring dumating din ang parehong URL sa pamamagitan ng partial, string ng pagsasalin o field ng database.
Sundin din ang mga redirect, dahil ang kadenang nagsisimula sa https:// ay maaaring mapunta sa lokasyong http:// at hinahatulan ng browser ang huling pagtalon. Ang anyo ng -L ikalawang utos sa itaas ay naglilimbag ng epektibong URL na iyon para sa iyo. Kung ang huling pagtalon ay purong http, mali pa rin ang reference kahit mukhang maayos ang link na in-edit mo.
Kumpirmahin ang pahina gamit ang console at panel ng network
I-reload nang patay ang cache at sundan muli ang daloy, kasama ang mga buton na naglo-load ng content kapag hiniling. Itinatago ng unang pag-load ng pahina ang mga tamad na widget, tile ng mapa at script ng player na lumalabas lamang pagkatapos ng pag-click. Wala dapat na entry ng mixed content sa console at dapat magpakita ng https ang bawat hilerong hinala mo. Kunan ng larawan ang console at ang hilera ng request bago isara ang ticket, dahil mahirap muling buuin ang estadong iyon pagkatapos ng susunod na deploy.
Kapag pag-aari ng iba ang resource, magpadala ng apat na bagay: ang eksaktong URL, uri ng request, teksto ng console at ang pahina kung saan ito lumalabas. Itago ang mga identifier ng session sa lahat ng ipapaste mo sa ticket. Ang ulat na sinasabi lamang na sira ang mga larawan ay walang ibinibigay na hahanapin sa may-ari.
Patuloy na ginagawa ng tunnel ang sarili nitong trabaho habang ang pag-aayos ay nasa reference na gumawa ng request. Pagkatapos ng deploy, hanapin muli ang pangalan ng host sa template at sa bundle ng vendor, at isara ang kaso lamang kapag wala nang natitirang naka-block na entry ng mixed content sa console.