Dokumentacija

Odpravite mešano vsebino

Odpravite mešano vsebino

Mešana vsebina je stran na https://, ki nekatere svoje dele naloži po navadnem http://: sliko, skript, slog, pisavo ali vdelan okvir. Stran sama je šifrirana, ti deli pa ne, zato bi jih lahko kdor koli v omrežju videl ali zamenjal. Brskalniki ukrepajo sami: skripte, sloge in okvirje kar blokirajo (drsnik neha delovati, obrazec izgubi oblikovanje, zemljevid izgine), slike in video poskusijo nadgraditi na https:// in jih izpustijo, če to ne uspe, stran pa prikažejo brez ključavnice.

Skoraj vedno izvira iz naslovov, zapisanih v vsebino ali kodo, preden se je stran preselila na HTTPS. Kontrolni seznam strani pove, koliko datotek je našel, in navede nekaj primerov.

Od kod pride

Vir Tipičen primer
vsebina v bazi slike, pred leti vstavljene v prispevke kot http://example.com/wp-content/uploads/…
tema ali predloga logotip ali skript s polnim naslovom http://, zapisanim v kodi
graditelj strani Elementor, Divi ali WPBakery hranijo absolutne naslove in ustvarjen CSS
vdelave in koda tretjih star pripomoček, zemljevid, pisava ali števec, vključen kot http://…
aplikacija ogrodje za proxyjem, ki misli, da je zahtevek prišel po HTTP, in gradi povezave http://

Povezave (<a href="http://…">) niso mešana vsebina: v stran ne naložijo ničesar.

Preverite sami

Najhitreje je v brskalniku. Odprite stran, pritisnite F12 (ali Cmd+Option+I na Macu), preklopite na zavihek Console in znova naložite stran. Vsaka težava se pokaže kot vrstica, na primer:

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure image 'http://example.com/logo.png'.

Za seznam iz ukazne vrstice (namesto example.com vpišite svojo stran):

curl -s https://example.com | grep -oiE '<(img|script|iframe|source|video|audio|embed)[^>]+src="http://[^"]+"|<link[^>]+href="http://[^"]+"' | sort -u

Popravljeno: konzola ne kaže nobene vrstice Mixed Content, ukaz pa ne izpiše ničesar. Preverite nekaj različnih vrst strani (domača stran, prispevek, izdelek); težava je pogosto samo v starejši vsebini.

Kako popraviti

Pravi popravek je, da naslove http:// spremenite v https:// tam, kjer so shranjeni. Najprej preverite, da vsaka datoteka na https:// res obstaja (naslov z https:// odprite v brskalniku). Nato izberite tisto, do česar imate dostop.

WordPress

  1. V Settings → General se morata WordPress Address (URL) in Site Address (URL) začeti s https://.
  2. Zamenjajte stare naslove v bazi. Najprej naredite varnostno kopijo. Uporabite orodje, ki razume serializirane podatke WordPressa; navaden SQL REPLACE pokvari pripomočke in nastavitve graditelja strani.

Z WP-CLI najprej poskusno, nato zares:

wp db export before-https.sql
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run
wp search-replace 'http://example.com' 'https://example.com' --all-tables

Brez ukazne vrstice uporabite brezplačni vtičnik Better Search Replace (Tools → Better Search Replace): poiščite http://example.com, zamenjajte z https://example.com, izberite vse tabele in ga najprej poženite poskusno (dry run).

  1. Elementor: Elementor → Tools → Replace URL naredi isto za podatke Elementorja. Nato na zavihku General istega zaslona znova ustvarite njegov CSS. Tudi drugi graditelji hranijo ustvarjen CSS; počistite ga v njihovih nastavitvah.
  2. Tema in pripomočki: v datotekah podrejene teme, v Appearance → Customize → Additional CSS ter v besedilnih ali HTML pripomočkih poiščite http://.
  3. Počistite vse predpomnilnike (WP Rocket, LiteSpeed Cache, predpomnilnik gostitelja, Cloudflare).

Kot hiter zasilni ukrep ima brezplačni vtičnik Really Simple SSL (zdaj Really Simple Security) popravljalnik mešane vsebine, ki med pošiljanjem strani http:// prepiše v https://. Skrije simptom; naslovi ostanejo v bazi, zato zamenjavo vseeno naredite.

Statični HTML

Poiščite v vseh datotekah naslove, ki kaj nalagajo po HTTP:

grep -rnE '(src|href|action)="http://|url\(.?http://' --include='*.html' --include='*.css' --include='*.js' .

Navadne povezave (<a href="http://…">) preskočite; niso mešana vsebina. Ostale spremenite v https://. Za datoteke na vaši domeni je še boljša pot od korena (/images/logo.png): deluje na vsaki domeni in protokolu. Če datoteka tretje strani po HTTPS ni na voljo, jo prenesite in strezite sami ali jo zamenjajte.

Laravel

Za razdelilnikom obremenitve, Cloudflarom ali drugim proxyjem Laravel prejme zahtevek po HTTP, in url(), asset() ter route() gradijo naslove http://. V bootstrap/app.php proxyju zaupajte, da Laravel bere X-Forwarded-Proto:

->withMiddleware(function (Middleware $middleware) {
    $middleware->trustProxies(at: '*');
})

Če so naslovi IP vašega proxyja stalni, '*' zamenjajte z njimi. V .env nastavite tudi APP_URL=https://example.com, ker ga uporabljajo opravila v vrsti in e-pošta. Nato v pogledih Blade in shranjeni vsebini poiščite vpisane http://.

Cloudflare

Pojdite na SSL/TLS → Edge Certificates in vklopite Automatic HTTPS Rewrites. Cloudflare nato v HTML-ju, ki ga posreduje, prepiše naslove http:// v https:// za vire, za katere ve, da delujejo po HTTPS, vključno z vašo domeno.

Pomaga samo pri prometu skozi proxy (oranžen oblak) in ne more popraviti vira, ki različice HTTPS nima. Naslovi ostanejo v vaši vsebini, zato jih popravite tudi pri viru.

nginx

Kot zasilni ukrep, dokler ne počistite vsebine, direktiva upgrade-insecure-requests brskalniku naroči, naj vsak vir strani z http:// namesto tega naloži po https://. V blok server za HTTPS (/etc/nginx/sites-available/example.com na Debianu in Ubuntuju, /etc/nginx/conf.d/example.com.conf na Rocky, Alma in CentOS):

add_header Content-Security-Policy "upgrade-insecure-requests" always;

sudo nginx -t && sudo systemctl reload nginx

Če glavo Content-Security-Policy že pošiljate, ji dodajte upgrade-insecure-requests;, namesto da pošljete drugo.

Apache in LiteSpeed

Kot zasilni ukrep ista direktiva upgrade-insecure-requests, v navideznem gostitelju strani ali v .htaccess v korenu strani (deluje tudi na LiteSpeedu):

<IfModule mod_headers.c>
    Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

Z dostopom do strežnika nato znova naložite: sudo apachectl configtest && sudo systemctl reload apache2 (httpd na Rocky, Alma in CentOS).

Opomba: upgrade-insecure-requests in Cloudflarovo prepisovanje poskrbita, da brskalnik datoteke naloži po HTTPS, naslovi http:// pa so še vedno v strani, zato jih kontrolni seznam navaja, dokler jih ne spremenite pri viru. Datoteka, ki na https:// ne obstaja, se namesto nevarnega nalaganja sploh ne naloži.

Gostovane platforme

Shopify, Wix, Squarespace in Webflow svoje datoteke strežejo po HTTPS. Mešana vsebina tam izvira iz tistega, kar je bilo dodano ročno: blok s kodo po meri ali vdelavo, skript, prilepljen v glavo, slika, vstavljena z naslovom, ali koda teme (v Shopifyju: Online Store → Themes → ⋯ → Edit code). Najdite jo s konzolo brskalnika in naslov v tem bloku spremenite v https://.

Potrdite popravek

Stran znova naložite z odprto konzolo brskalnika in znova poženite ukaz curl iz razdelka Preverite sami, nato v PulseKeeperju odprite tarčo in na zavihku Kontrolni seznam kliknite Preveri zdaj.