Lata temu napisałem post, w którym udostępniłem funkcję publiczną, aby ustalić, czy użytkownik ma uprawnienia do zapisywania informacji w bazie danych WordPressa. Oryginał w całej okazałości (wraz z solidnymi komentarzami) możecie zobaczyć tutaj (ma nawet pięć lat – wow).
Jak w przypadku wszystkiego, co jest związane z programowaniem, czas płynie, rzeczy są udoskonalane i [miejmy nadzieję] stają się lepsze niż wcześniej.
Chociaż nadal używam i polecam wariant funkcji user_can_save (lub userCanSave ), uważam również, że ważne jest, aby przejść przez proces wyodrębniania procesu weryfikacji żądania.
Więc teraz nie chodzi tylko o ustalenie, czy użytkownik ma uprawnienia, ale o weryfikację informacji o zabezpieczeniach pochodzących od klienta – czy to za pośrednictwem poczty z powrotem do serwera, czy żądania wysłanego przez Ajax – i zrobienie tego przy użyciu dobrych technik programowania, które są zgodne zarówno z WordPress, jak i z PHP.
Aby było jasne, chodzi bardziej o bezpieczne przesyłanie formularzy WordPress ze strony opcji lub strony ustawień niż, powiedzmy, formularz pochodzący z szablonu. To kolejny post na inny czas.
Ale wciąż jest wielu z nas pracujących nad tworzeniem aplikacji na WordPressie, które wymagają następujących rzeczy.
Bezpieczne przesyłanie formularzy WordPress
W tym poście nie zamierzam przejmować się szczegółami określania, czy coś jest autozapisem, czy wersją postu.
Jednak zamierzam przejść przez proces przejmowania funkcji odpowiedzialnej za walidację przychodzących informacji i robienia tego przy użyciu nowoczesnego podejścia z wykorzystaniem praktyk zorientowanych obiektowo oraz zarówno API WordPressa, jak i funkcji PHP.
1 Zaczynając od poziomu ogólnego
Z poziomu podstawowego załóżmy, że istnieje klasa bazowa, z której istnieją inne podklasy wykorzystujące tę funkcję. To mówi nam, że musimy użyć chronionego modyfikatora widoczności.
Wiemy również, że będziemy mieli do czynienia z wartością WordPress nonce i powiązaną akcją. Oznacza to, że podpis funkcji będzie wyglądał mniej więcej tak :
2 Oczyść dane, zweryfikuj nicość
Jak na wszystko, co jest wysyłane na serwer, wiemy, że będziemy musieli zweryfikować, czy dane są ustawione, a jeśli tak, będziemy musieli oczyścić informacje.
Oznacza to, że będziemy potrzebować następujących funkcji:
Wiemy też, że będziemy musieli zweryfikować wartość jednorazową, więc będziemy też potrzebować wp_verify_nonce.
3 Pierwsze przejście do pracy
Działający pierwszy przebieg tej funkcji może wyglądać mniej więcej tak:
Ale co, jeśli ktoś udostępnia dane, które wysłały żądanie POST (w przeciwieństwie do żądania GET )? Następnie możemy zmodyfikować funkcję tak, aby wyglądała mniej więcej tak:
I to by wystarczyło. Ale jeśli naprawdę chcemy, aby dana funkcja była tak czysta, jak to tylko możliwe, moglibyśmy to rozbić jeszcze bardziej.
4 Funkcja do każdego celu
Biorąc pod uwagę powyższy kod, wiemy, że musimy obsługiwać zarówno żądania GET, jak i żądania POST. PHP oferuje funkcję filter_input, która jest pomocna, łatwiejsza do odczytania (cóż, jest to subiektywne), ale także przechodzi kilka kontroli jakości kodu.
Co więcej, możemy użyć prostej funkcji fabrycznej, aby podzielić logikę na oddzielne funkcje, takie jak ta:
Najpierw musimy napisać dwie oddzielne funkcje – jedną dla żądania POST:
I jeden na żądanie GET:
Następnie możemy połączyć to w oryginalną funkcję w ten sposób:
Czyste zarządzanie przychodzącymi żądaniami
Być może wygląda to na skomplikowany sposób obsługi prostego rozwiązania, biorąc pod uwagę początkowy zestaw kodu, który został udostępniony.
Jest to z pewnością możliwe, zwłaszcza jeśli jesteś pod presją czasu lub nie zależy ci tak bardzo na dzieleniu rzeczy na najmniejsze możliwe atomowe (lub nawet testowalne) komponenty.
Ale jeśli chcesz pisać kod obiektowy z najwyższą precyzją, być może ten proces właśnie w tym pomoże.