Chcę odfiltrować dowolny identyfikator URI żądania HTTP wykonany za pośrednictwem interfejsu API HTTP.
Przypadków użycia:
- Sprawdzanie aktualizacji WordPress przechodzi do http://api.wordpress.org/core/version-check/1.6/ , ale https://api.wordpress.org/core/version-check/1.6/ też działa, i chcę używać tego zawsze.
- Nowy plik WordPress pochodzi z http://wordpress.org/wordpress-3.4.2.zip , ale https://wordpress.org/wordpress-3.4.2.zip również działa.
- Czasami chcę debugować żądania i przekierowywać je tymczasowo do niestandardowej domeny na moim serwerze lokalnym.
- Niektóre wtyczki wysyłają żądania do innych serwerów i chcę je zastąpić, gdy serwer zewnętrzny ulegnie awarii.
Żądania aktualizacji są na razie najważniejsze, ponieważ wciąż istnieje nierozwiązany błąd 16778 ( więcej informacji ), a żądania HTTPS zmniejszają ryzyko ataku Man-in-the-middle.
Mam szukał dokładnie , ja badali kod rdzenia ... ale skończyło się jak Nacin dwa lata temu:
Pomyślałem, że możesz odfiltrować adres URL żądania HTTP, ale teraz nie mogę go znaleźć.
Co mnie ominęło? Czy ja? :)
Odpowiedzi:
Mniej niż odpowiedź, ale tylko lista rzeczy prosto z mojego doświadczenia - może coś przeoczyłeś.
Debugowanie żądania i jego wyników
Bez diggin „zbyt głęboko w proces aktualizacji, ale WP HTTP API używa
WP_HTTP
klasy. Oferuje również fajną rzecz: hak debugowania.Gdzie
$response
może być takżeWP_Error
przedmiot, który może powiedzieć ci więcej.Uwaga: po krótkim teście ten filtr wydaje się (z jakiegoś powodu) działać tylko wtedy, gdy umieścisz go tak blisko miejsca, w którym faktycznie wykonujesz żądanie. Może więc trzeba zadzwonić z oddzwaniania na jednym z poniższych filtrów.
WP_HTTP
Argumenty klasoweSame argumenty Klasy są filtrowalne, ale niektóre z nich są resetowane przez wewnętrzne metody z powrotem do tego, co WP zakłada, że jest potrzebne.
Jednym z argumentów jest
ssl_verify
, co jest prawdą domyślnie (ale dla mnie powoduje ogromne problemy podczas aktualizacji z - na przykład - GitHub). Edycja: Po debugowaniu żądania testowego znalazłem inny argument, który jest ustawiony, aby sprawdzić, czy SSL jest ustawiony natrue
. Nazywa sięsslverify
(bez oddzielania podkreślenia). Nie mam pojęcia, gdzie to się pojawiło, czy jest faktycznie używane, czy porzucone i czy masz szansę wpłynąć na jego wartość. Znalazłem to za pomocą'http_api_debug'
filtra.Całkowicie niestandardowy
Możesz również „po prostu” zastąpić wszystkie elementy wewnętrzne i przejść do niestandardowej konfiguracji. Jest do tego filtr.
Pierwszy argument musi być ustawiony na true. Następnie możesz wchodzić w interakcje z argumentami wewnątrz
$r
i wynikamiparse_url( $url );
.Pełnomocnik
Kolejną rzeczą, która może działać, może być uruchamianie wszystkiego za pośrednictwem niestandardowego serwera proxy. To wymaga pewnych ustawień w twoim
wp-config.php
. Nigdy wcześniej tego nie próbowałem, ale jakiś czas temu przeglądałem stałe i podsumowałem kilka przykładów, które powinny zadziałać, i zamieściłem komentarze na wypadek, gdyby tego potrzebowałem. Musisz zdefiniowaćWP_PROXY_HOST
iWP_PROXY_PORT
jako min. oprawa. W przeciwnym razie nic nie będzie działać i po prostu obejdzie serwer proxy.EDYTOWAĆ
WP_HTTP
Klasy zazwyczaj działa jako podstawowej klasy (będzie przedłużony o różnych scenariuszach). PrzebiegająceWP_HTTP_*
zajęcia sąFsockopen
,Streams
,Curl
,Proxy
,Cookie
,Encoding
. Jeśli podłączysz wywołanie zwrotne do'http_api_debug'
-action, trzeci argument powie ci, która klasa została użyta dla twojego żądania.Wewnątrz
WP_HTTP_curl
klasy znajdzieszrequest()
metodę. Ta metoda oferuje dwa filtry do przechwytywania zachowania SSL: jeden dla żądań lokalnych'https_local_ssl_verify'
i jeden dla żądań zdalnych'https_ssl_verify'
. WP prawdopodobnie zdefiniujelocal
jakolocalhost
i to, co otrzymasz w zamianget_option( 'siteurl' );
.Chciałbym więc spróbować wykonać następujące czynności bezpośrednio przed wykonaniem tego żądania (lub z wywołania zwrotnego, które jest powiązane z najbliższym żądaniem:
Sidenote: W większości przypadków
WP_HTTP_curl
będą używane do obsługi proxy.źródło
pre_http_request
, anulować żądanie i wysłać je ponownie z poprawnym adresem URL. Spróbuję tego dziś wieczorem.Na podstawie użytecznej odpowiedzi @ kaiser napisałem kod, który wydaje się działać dobrze. To dlatego oznaczyłem to jako odpowiedź.
Pozwól mi wyjaśnić moje rozwiązanie…
Logika
Kiedy żądanie wysłane przez API jest uruchamiane
WP_Http::request()
. To metoda z…… W nagłówku. Nie mogłem się więcej zgodzić.
Teraz jest kilka filtrów. Postanowiłem nadużyć
pre_http_request
do moich potrzeb:Dostajemy trzy argumenty tutaj:
false, $r, $url
.false
jest oczekiwaną wartością zwracaną dlaapply_filters()
. Jeśli odeślemy cokolwiek innego, WordPress zatrzymuje się natychmiast, a pierwotne żądanie nie zostanie wysłane.$r
jest tablicą argumentów dla tego żądania. Te też musimy zmienić za minutę.$url
jest - niespodzianka! - adres URL.Więc w naszym wywołaniu zwrotnym
t5_update_wp_per_https()
patrzymy na adres URL, a jeśli jest to adres URL, który chcemy filtrować, mówimy NIE WordPressowi, nie mówiąc „nie” (false
).Uwaga dodatkowa: Wynika z tego, że możesz zapobiec wszystkim żądaniom HTTP za pomocą:
add_filter( 'pre_http_request', '__return_true' );
Zamiast tego uruchamiamy własne żądanie z lepszym adresem URL i nieznacznie dostosowanymi argumentami (
$r
zmieniono ich nazwy$args
na czytelne).Kod
Przeczytaj wbudowane komentarze, są one ważne.
Testy
Bez tej wtyczki WordPress zastosował:
http://api.wordpress.org/core/version-check/1.6/
do kontroli aktualizacji orazhttp://wordpress.org/wordpress-3.4.2.zip
aby pobrać nowe pliki.Przetestowałem to z dwiema lokalnymi instalacjami, jedną witryną i instalacją obejmującą wiele witryn w systemie Win 7. Aby wymusić aktualizację,
$wp_version
wwp-includes/version.php
której się wprowadziłem,1
i wersję TwentyEleven na1.3
.Do oglądania ruchu sieciowego użyłem Wireshark : jest bezpłatny, działa w systemach Windows i Linux oraz oferuje imponujące narzędzia do filtrowania.
Oglądanie HTTPS jest trochę trudne: widzisz tylko zaszyfrowane dane… w końcu taki jest pomysł. Aby sprawdzić, czy moja wtyczka działa tak, jak powinna, najpierw obserwowałem niezaszyfrowany ruch i zanotowałem adres IP używany do łączenia się z wordpress.org.
72.233.56.138
Czasami tak było72.233.56.139
.Nic dziwnego, że istnieje moduł równoważenia obciążenia i prawdopodobnie wiele innych narzędzi, więc nie możemy polegać na jednym adresie IP.
Następnie wpisałem
ip.addr == 72.233.56.138
maskę filtra, aktywowałem wtyczkę, podszedłem dowp-admin/update-core.php
i obserwowałem ruch w Wireshark. Zielone linie to żądania w postaci zwykłego tekstu - dokładnie tego, czego nie chcemy. Czerwone i czarne linie są znakiem sukcesu.Sprawdzenie aktualizacji przebiegło pomyślnie: znaleziono „nowsze” wersje. Rzeczywiste aktualizacje motywu i rdzenia również poszły dobrze. Dokładnie to, czego potrzebowałem.
A jednak… to mogłoby być łatwiejsze, gdyby istniał prosty filtr adresu URL.
źródło
/* /**/
, tylko dlatego, że jest genialny. I (gdybym mógł) kolejne +1 dla Charlesa Bronsona. A potem powinno być kolejne +1 za szczegółowe wyjaśnienia, komentarze i zrzuty ekranu.źródło