Багато років тому я написав допис, у якому поділився загальнодоступною функцією визначення, чи має користувач дозволи на збереження інформації в базі даних WordPress. Ви можете побачити оригінальну суть у всій її застарілій красі (разом із суцільними коментарями) тут (йому навіть п’ять років – вау).
Як і у всьому, що пов’язано з програмуванням, час минає, все вдосконалюється, і все [сподіваємось] стає краще, ніж було раніше.
Хоча я все ще використовую та рекомендую варіант функції user_can_save (або userCanSave ), я також вважаю, що важливо пройти процес відокремлення процесу перевірки запиту.
Отже, тепер мова йде не лише про визначення, чи має користувач дозволи, але й про перевірку інформації про безпеку, що надходить від клієнта – через повідомлення на сервер або запит, зроблений через Ajax – і робити це за допомогою хороших методів програмування, які узгоджуються як з WordPress, так і з PHP.
Щоб було зрозуміло, це більше стосується безпечного надсилання форми WordPress зі сторінки параметрів або сторінки налаштувань, ніж, скажімо, форми, отриманої з шаблону. Це інший пост іншим разом.
Але все ж багато з нас працюють над створенням додатків на WordPress, і для цього потрібно наступне.
Безпечне надсилання форм WordPress
У цій публікації я не буду турбуватися про те, як визначити, чи є щось автозбереженням чи публікацією.
Однак я збираюся пройти через процес прийняття функції, яка відповідає за перевірку вхідної інформації, і робити це з використанням сучасного підходу з використанням об’єктно-орієнтованих методів і як API WordPress, так і функцій PHP.
1 Починаючи з загального рівня
З базового рівня припустімо, що існує базовий клас, з якого є інші підкласи, які використовують цю функцію. Це означає, що нам потрібно використовувати модифікатор видимості protected.
Ми також знаємо, що матимемо справу з одноразовим значенням WordPress і пов’язаною дією. Це означає, що сигнатура функції виглядатиме приблизно так :
2 Очистіть дані, перевірте Nonce
Щодо всього, що опубліковано на сервері, ми знаємо, що нам потрібно буде перевірити, чи встановлено дані, і якщо так, нам потрібно буде очистити інформацію.
Це означає, що нам знадобляться такі функції:
І ми також знаємо, що нам потрібно буде перевірити nonce, тому нам також знадобиться wp_verify_nonce.
3 Робочий перший прохід
Робочий перший прохід цієї функції може виглядати приблизно так:
Але що, якщо хтось ділиться даними, які надіслали запит POST (а не GET )? Тоді ми могли б змінити функцію, щоб вона виглядала приблизно так:
І цього було б достатньо. Але якщо ми справді хочемо, щоб дана функція була максимально чистою, тоді ми можемо розбити це ще далі.
4 Функція для кожної мети
Враховуючи наведений вище код, ми знаємо, що нам потрібно обробляти як запити GET, так і запити POST. PHP пропонує функцію filter_input, яка є корисною, легшою для читання (ну, це суб’єктивно), але також проходить кілька перевірок якості коду.
Крім того, ми можемо використати просту фабричну функцію, щоб розділити логіку на такі функції:
По-перше, нам потрібно написати дві окремі функції – одну для запиту POST:
І один для запиту GET:
Тоді ми можемо зв’язати це разом у вихідній функції так:
Чітке керування вхідними запитами
Можливо, це виглядає як складний спосіб обробки простого рішення, враховуючи початковий набір коду, який надавався спільно.
Це, звичайно, можливо, особливо якщо у вас обмежений час або ви не дуже дбаєте про розбиття речей на найменші можливі атомарні (або навіть перевірені) компоненти.
Але якщо ви хочете написати об’єктно-орієнтований код із найвищим ступенем точності, можливо, цей процес допоможе саме в цьому.