Zwykle używam tego argumentu, aby zapobiec błędom z wp_remote_getiwp_remote_post
array(
'sslverify' => false
)Ze względów bezpieczeństwa chciałbym ustawić go na true(lub usunąć, ponieważ domyślnie jest to prawda).
Czy powinienem spodziewać się jakichkolwiek problemów?
Odpowiedzi:
TL; DR: Tak, usuń to ustawienie z WordPress 3.7 lub nowszego.
W przeszłości wiele osób dodawało parametr sslverify = false, ponieważ ich instalacja PHP nie była w stanie poprawnie zweryfikować certyfikatu.
Zazwyczaj było to spowodowane tym, że instalacja PHP nie została zaktualizowana o najnowszą kopię certyfikatów głównych CA. Certyfikaty główne zmieniają się tak często i zwykle nie zauważasz tej zmiany, ponieważ dzieje się to w normalnych aktualizacjach przeglądarki. Cóż, jeśli PHP działa jak przeglądarka, aby pobierać adresy URL https, wtedy potrzebuje również tych aktualizacji certyfikatu głównego. Większość hostów nigdy nie aktualizuje PHP ani nie aktualizuje żadnej jego określonej części (np. Pliku certyfikatów).
Kiedy WordPress wdrożył automatyczną aktualizację w wersji 3.7, ustalono, że konieczne jest uaktualnienie interfejsów API WordPress.org, aby wymagać bezpiecznej komunikacji. W tym czasie WordPress zaczął dołączać kopię samego pliku certyfikatów głównych CA, pochodzących z Mozilli. Dlatego od wersji WordPress 3.7 funkcje API WP_HTTP używają tego pliku do weryfikacji certyfikatu, a nie jakakolwiek stara lub nieaktualna wersja jest spakowana z instalacją PHP.
Dlatego tak, w WordPress 3.7 lub nowszym wskazane jest usunięcie parametru sslverify i umożliwienie funkcji http prawidłowej weryfikacji certyfikatu. Każdy nowoczesny serwer z protokołem SSL z kluczem podpisanym przez jeden ze znanych urzędów certyfikacji zostanie poprawnie zweryfikowany. WP_HTTP powinien mieć kopię najnowszych certyfikatów głównych, a główny projekt zaktualizuje ten plik certyfikatów w WordPressie wraz z normalnymi aktualizacjami.
Istnieje wiele powodów, dla których weryfikacja SSL może się nie powieść. Począwszy od zbyt wielu przekierowań do niewłaściwych .iniplików / konfiguracji lub po prostu brakujących certyfikatów lub subdomen. W każdym razie musisz znaleźć przyczynę tego i naprawić . Jest nie sposób wokół niego.
Aby jednak tymczasowo obejść ten problem (powiedzmy, że musisz dalej rozwijać swój kod i naprawić błąd SSL), możesz użyć filtra:
add_filter( 'https_ssl_verify', '__return_false' );Gdy uruchamiasz to podczas zdalnego żądania, powinieneś zawinąć go w wywołanie zwrotne dołączone do filtru, który jest wyzwalany podczas takiego żądania HTTP. Upewnij się, że naprawdę usuwasz weryfikację poprawnej sprawy - i upewnij się, że uruchomisz ją tylko raz, aby nie zabezpieczyć innych żądań.
add_filter( 'http_request_args', function( $params, $url )
{
// find out if this is the request you are targeting and if not: abort
if ( 'foo' !== $params['foo'] )
return $params;
add_filter( 'https_ssl_verify', '__return_false' );
return $params;
}, 10, 2 );Jeśli jest to publicznie rozpowszechniana wtyczka, możesz dołączyć ją do prostej opcji, którą użytkownik może włączyć lub wyłączyć. Równie dobrze możesz najpierw wypróbować zweryfikowane żądanie, a jeśli nie (a jeśli użytkownik wybrał niepodpisane żądanie), przejdź do potencjalnie niebezpiecznego żądania.
Praktyczna zasada:
Nigdy nie wykonuj niezabezpieczonego żądania, dopóki użytkownik nie wyrazi na to zgody i nie zna ryzyka.
WordPress może polegać na bazowym oprogramowaniu serwera (zwykle cURL), aby wykonać żądanie sieciowe. W skrócie, bo właśnie to oprogramowanie jest dobre i do tego służy.
Na niektórych serwerach z różnych powodów (nigdy nie przejmowałem się spojrzeniem na siebie) jest dość typowe, że oprogramowanie serwera nie jest w stanie „zweryfikować” bezpiecznych połączeń, powodując wspomniane błędy.
Więc: