Jeśli Twoja witryna działa za Cloudflare i masz aktywną regułę rate limiting, ta reguła może obejmować także API REST WP STAGING. Cloudflare odpowiada wtedy na takie żądania kodem HTTP 429 (Too Many Requests), a funkcje WP STAGING zależne od API REST przestają działać. Rozwiązaniem jest jednolinijkowy wyjątek w regule rate limiting.
Dlaczego rate limiting Cloudflare psuje API REST WP STAGING?
Reguły rate limiting w Cloudflare są sprawdzane na przychodzącym żądaniu, a nie na wtyczce, która je wysłała. Reguła napisana dla całej domeny albo dla obciążonej ścieżki takiej jak /booking zlicza więc również wewnętrzne żądania, które WP STAGING kieruje do własnego API REST.
Po przekroczeniu licznika Cloudflare blokuje kolejne pasujące żądania i zwraca HTTP 429. WP STAGING w ogóle nie dociera do WordPressa, więc funkcja, która wywołała żądanie, kończy się błędem albo zawiesza.
Twoja witryna jest dotknięta problemem, jeśli spełnione są wszystkie poniższe warunki:
- Rate limiting Cloudflare jest włączony dla strefy.
- Reguła rate limiting obejmuje witrynę WordPress lub ścieżkę w jej obrębie, na przykład
/booking. - Ta reguła nie wyklucza API REST WP STAGING.
Które funkcje WP STAGING przestają działać?
Z API REST WP STAGING korzysta kilka funkcji, między innymi:
- Zadania w tle
- Remote Sync
- Magic Login
- Automatyczne aktualizacje wtyczek
- Inne funkcje oparte na API REST
Jeśli te żądania zostaną ograniczone, kończą się błędem HTTP 429, a funkcja, która je uruchomiła, nie może się zakończyć.
Jak wykluczyć API REST WP STAGING z rate limitingu Cloudflare?
Zmodyfikuj regułę rate limiting tak, aby przestała obejmować żądania do API REST WP STAGING.
Krok 1: otwórz swoje reguły rate limiting
W panelu Cloudflare wybierz konto, a następnie domenę, przejdź do sekcji Security i otwórz Security rules. Znajdziesz tam listę reguł rate limiting.
Krok 2: edytuj regułę obejmującą witrynę WordPress
Otwórz regułę, która obejmuje witrynę WordPress lub ścieżkę, na której pojawiają się odpowiedzi 429.
Krok 3: dodaj wyjątek do wyrażenia reguły
Dopisz ten warunek do wyrażenia dopasowania reguły:
and not http.request.uri.query contains "/wpstg/v1"Pełne wyrażenie dla reguły chroniącej /booking wygląda wtedy tak:
(http.host eq "example.com" and starts_with(http.request.uri.path, "/booking")) and not http.request.uri.query contains "/wpstg/v1"Krok 4: wdróż regułę
Zapisz i wdróż. Żądania takie jak poniższe nie są już ograniczane, a reszta witryny pozostaje chroniona:
?rest_route=/wpstg/v1/check_magic_loginUwaga:
wpstg/v1jest częścią ciągu zapytania, a nie ścieżki adresu URL. WP STAGING wywołuje swoje API REST w formie?rest_route=, dlatego w wyjątku użyjhttp.request.uri.query, a niehttp.request.uri.path.
FAQ
Dlaczego wyjątek używa http.request.uri.query, a nie http.request.uri.path?
WP STAGING buduje adresy REST w postaci https://example.com/?rest_route=/wpstg/v1/<endpoint>. Przestrzeń nazw wpstg/v1 znajduje się więc w ciągu zapytania. Reguła sprawdzająca http.request.uri.path nigdy by jej nie zobaczyła, a wyjątek nie zadziałałby wcale.
Czy ten wyjątek osłabia ochronę witryny?
Zwalnia wyłącznie żądania, których ciąg zapytania zawiera /wpstg/v1. Wszystkie pozostałe żądania do Twojej domeny nadal liczą się do reguły rate limiting.
Widzę błędy 429 również na /wp-json/wpstg/v1/. Co wtedy?
Niektóre konfiguracje sięgają do API REST przez formę z bezpośrednimi odnośnikami. W takim przypadku dodaj drugi warunek dla ścieżki:
and not starts_with(http.request.uri.path, "/wp-json/wpstg/v1/")Czy błąd 429 może mieć inną przyczynę niż Cloudflare?
Tak. Zapory aplikacji webowych, rate limiting po stronie hostingu i wtyczki bezpieczeństwa również mogą zwracać HTTP 429. Sprawdź logi serwera i wtyczek, jeśli błędy występują nadal po wdrożeniu wyjątku w Cloudflare.
Jak potwierdzić, że poprawka zadziałała?
Uruchom ponownie funkcję, która zawodziła, na przykład otwórz link Magic Login albo rozpocznij Remote Sync, i sprawdź dziennik Security Events w Cloudflare. Żądania zawierające /wpstg/v1 nie powinny już pokazywać akcji blokady przez rate limiting.
