Mixed content w WordPress po przejściu na https

Certyfikat jest zainstalowany, witryna ładuje się przez https, a kłódka wciąż nie chce się pojawić. To właśnie mixed content, czyli mieszana treść: sama strona przyszła przez https, ale coś w środku — obrazek, arkusz stylów, skrypt — nadal jest pobierane zwykłym http://. Ten artykuł przeprowadzi cię przez znalezienie tych adresów, podmianę ich bez uszkodzenia danych serializowanych, poprawienie siteurl i home oraz wymuszenie https na poziomie serwera, żeby problem nie mógł wrócić.

Czym właściwie jest mieszana treść

Zainstalowanie certyfikatu zmienia sposób szyfrowania połączenia. Nie zmienia tego, o co proszą twoje strony. Każdy adres http://yoursite.com/wp-content/uploads/logo.png, który przed przenosinami trafił do wpisu, widgetu czy ustawienia motywu, nadal siedzi w bazie danych, a przeglądarka posłusznie pobiera go przez niezabezpieczone połączenie.

Przeglądarki traktują dwie kategorie inaczej, a różnica ma znaczenie, gdy oceniasz, jak pilna jest sprawa:

• Aktywna mieszana treść — skrypty, arkusze stylów, ramki iframe, XHR. Blokowana całkowicie. Dlatego witryna po przejściu na https potrafi wyglądać na zepsutą bez żadnego komunikatu o błędzie: arkusz stylów został po cichu odrzucony.
• Pasywna mieszana treść — obrazy, dźwięk, wideo. Zwykle nadal się ładuje, ale kłódka zostaje obniżona, a część przeglądarek pokazuje oznaczenie „niezabezpieczona”.

Warto naprawić jedno i drugie. Tylko pierwsze faktycznie psuje działanie.

Krok 1: ustal, co nadal jest niezabezpieczone

Zacznij w przeglądarce. Otwórz stronę, otwórz narzędzia deweloperskie i przeczytaj konsolę. Każde zablokowane lub obniżone żądanie jest tam wymienione z pełnym adresem. To mówi ci, co jest niezabezpieczone; nie mówi, gdzie to jest zapisane.

Po to trzeba zajrzeć wprost do bazy danych. Wyeksportuj ją i przeszukaj zrzut:

wp db export dump.sql
grep -o "http://example\.com[^\"']*" dump.sql | sort -u | head -50

Jeśli WP-CLI nie jest dostępne, ten sam plik utworzy mysqldump:

mysqldump -u USER -p DBNAME > dump.sql

Przeczytaj zwrócone unikalne adresy. Ścieżki do katalogu uploads wskazują na treść wpisów i metadane. Ścieżki do zasobów motywu zwykle wskazują na opcje. Wszystko z domeną, której nie rozpoznajesz, to osadzenie zewnętrzne, a to wymaga innego rozwiązania (opisanego niżej).

Krok 2: najpierw popraw siteurl i home

siteurl i home to dwie opcje, z których WordPress buduje niemal każdy generowany przez siebie adres wewnętrzny. Jeśli którakolwiek nadal ma http://, WordPress będzie dalej wypuszczał niezabezpieczone adresy, choćby reszta bazy była idealnie czysta.

Sprawdź je:

wp option get siteurl
wp option get home

Albo w sql:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Te dwie wartości to zwykłe ciągi znaków, nie tablice serializowane, więc bezpośrednia aktualizacja sql jest tu naprawdę bezpieczna:

UPDATE wp_options
SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com')
WHERE option_name IN ('siteurl', 'home');

Jedna pułapka, zanim poświęcisz na to czas. Jeśli plik wp-config.php definiuje stałe WP_HOME lub WP_SITEURL, całkowicie nadpisują one bazę danych i twoja aktualizacja będzie wyglądać, jakby nic nie zrobiła:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Zaktualizuj je tam albo usuń i pozwól decydować bazie danych. Sprawdź to na początku — wyjaśnia to sporo przypadków w stylu „zmieniłem i nic się nie stało”.

Krok 3: zamiana musi być bezpieczna dla serializacji

Reszta bazy danych to miejsce, gdzie leży prawdziwe ryzyko, i nie jest to ryzyko, którego większość ludzi się spodziewa. Niebezpieczeństwo nie polega na tym, że zamiana pominie jakieś adresy. Polega na tym, że uda się na poziomie tekstu i zniszczy otaczające dane.

WordPress przechowuje tablice i obiekty jako ciągi serializowane przez php, a ten format zapisuje długość w bajtach każdego ciągu, który zawiera:

a:1:{s:4:"logo";s:38:"http://example.com/img/logo.png";}

Zamień http:// na https:// surowym poleceniem REPLACE w sql, a tekst wydłuży się o jeden bajt, podczas gdy zadeklarowana długość zostanie na starej wartości. php odczytuje długość, przesuwa się o tyle bajtów, nie znajduje tam oczekiwanego znaku zamykającego i odmawia deserializacji całej tablicy. WordPress podaje wtedy motywowi lub wtyczce wartość, która zachowuje się tak, jakby ustawienie nigdy nie zostało zapisane.

Objawem nie jest komunikat o błędzie. Objawem są znikające widgety, resetujące się ustawienia personalizacji i puste układy z kreatorów stron — bez żadnego śladu w panelu, że cokolwiek poszło nie tak. Odzyskanie tego bez kopii zapasowej jest naprawdę bolesne, więc ją zrób:

wp db export backup-before-https-replace.sql

Następnie użyj narzędzia, które deserializuje dane, podmienia je wewnątrz odkodowanej struktury i serializuje ponownie z poprawionymi długościami. Najpierw przebieg próbny:

wp search-replace 'http://example.com' 'https://example.com' --dry-run --all-tables --skip-columns=guid

Przeczytaj raport. Jeśli tabela, której nie rozpoznajesz, pokazuje tysiące trafień, zatrzymaj się i sprawdź, zanim to zatwierdzisz. Potem uruchom na serio:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid --report-changed-only

--skip-columns=guid ma znaczenie: guid to trwały identyfikator dla czytników kanałów, a nie działający adres, i jego przepisanie może sprawić, że subskrybenci zobaczą całe twoje archiwum jako nowe wpisy. Jeśli przed uruchomieniem czegokolwiek chcesz sprawdzić, które kolumny są bezpieczne dla zwykłego sql, a które wymagają obsługi świadomej serializacji, zbuduj zapytania narzędziem do wyszukiwania i zamiany sql w WordPress.

Jeśli nie możesz korzystać z wiersza poleceń, wtyczka migracyjna, która wprost deklaruje obsługę danych serializowanych, wykona tę samą pracę dekodowania z poziomu panelu. Jeśli narzędzie tego nie deklaruje, zakładaj, że tego nie potrafi.

Krok 4: wymuś https na serwerze

Wyczyszczenie bazy sprawia, że twoje strony przestają prosić o niezabezpieczone zasoby. Nie powstrzymuje odwiedzającego przed wejściem przez http:// w pierwszej kolejności. Do tego służy przekierowanie na poziomie serwera, a w Apache jego miejsce jest w pliku .htaccess:

# BEGIN Force HTTPS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
# END Force HTTPS

Dwie uwagi o miejscu. Umieść to powyżej znaczników # BEGIN WordPress — wszystko w środku jest kasowane, gdy tylko ktoś zapisze bezpośrednie odnośniki. I działa to tylko wtedy, gdy mod_rewrite jest włączony, a host wirtualny pozwala na nadpisania (AllowOverride All albo przynajmniej FileInfo). W nginx plik .htaccess jest całkowicie ignorowany i to musi trafić do bloku serwera.

RedirectMatch nie wykona tego zadania. Dopasowuje wyłącznie ścieżkę żądania i nie ma jak sprawdzić, czy bieżące żądanie jest już bezpieczne, więc przekierowuje żądania https na nie same. Warunkowa reguła RewriteRule powyżej to właściwe narzędzie.

Pętla przekierowań i skąd się bierze

Jeśli witryna zaczyna przekierowywać w nieskończoność w chwili dodania tej reguły, twoje TLS kończy się gdzieś wyżej — na load balancerze, serwerze reverse proxy albo w sieci CDN — a ten przekazuje do Apache zwykłe http. Apache widzi niezabezpieczone żądanie, przekierowuje na https, proxy znowu podaje http i tak w kółko.

Sprawdzaj zamiast tego nagłówek przekazany dalej:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Sam WordPress ma w takiej konfiguracji tę samą ślepą plamkę — is_ssl() czyta $_SERVER['HTTPS'], czego proxy nigdy nie ustawia, więc adresy panelu wychodzą jako http://. Dodaj to do wp-config.php, powyżej linii „stop editing”:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

Warto uczciwie powiedzieć o ryzyku: X-Forwarded-Proto to nagłówek dostarczany przez klienta. Ufanie mu jest poprawne tylko wtedy, gdy kontrolowane przez ciebie proxy zawsze go nadpisuje. Na serwerze osiągalnym bezpośrednio z internetu można go sfałszować.

Czego zamiana w bazie danych nie naprawi

• Adresy zapisane na sztywno w plikach. Wszystko, co trafiło do functions.php, szablonu motywu potomnego albo osadzonej ścieżki do zasobu, nie jest w bazie danych. Przeszukaj katalog motywu osobno.
• JSON ze znakami ucieczki. Część kreatorów zapisuje adresy jako https:\/\/example.com. Wyszukiwanie zwykłej postaci całkowicie je pomija, więc może być potrzebny drugi przebieg na wersji ze znakami ucieczki.
• Zasoby zewnętrzne. Skryptu ani osadzenia od zewnętrznego dostawcy, dostępnego wyłącznie przez http, nie naprawisz po swojej stronie. Znajdź wersję na https albo z tego zrezygnuj.
• Pamięci podręczne. Cache stron, cache obiektów i kopie w sieci CDN nadal serwują stary kod po poprawnie wykonanej zamianie. Wyczyść wszystkie trzy, zanim uznasz, że zamiana się nie udała.

Jedna rzecz, którą warto pominąć: nagłówek Content Security Policy upgrade-insecure-requests uciszy ostrzeżenia, przepisując niezabezpieczone żądania w przeglądarce. Leczy objaw i zostawia błędne adresy w bazie danych, skąd kolejny eksport, migracja albo kanał poniesie je dalej. Napraw najpierw dane, a potem — jeśli chcesz — użyj go jako siatki bezpieczeństwa.

Nadal utknąłeś?

Sprawdzaj siteurl i home po każdym kroku — wtyczki i narzędzia migracyjne czasem przepisują je za twoimi plecami. Jeśli konsola nadal wskazuje niezabezpieczony adres, którego nie możesz znaleźć w zrzucie, obejrzyj źródło strony i poszukaj go tam: jeśli pojawia się w wygenerowanym kodzie, ale nie w bazie danych, jest budowany w php, a naprawić trzeba motyw lub wtyczkę, która go produkuje.