Несколько лет назад я написал пост, в котором поделился общедоступной функцией, чтобы определить, есть ли у пользователя разрешения на сохранение информации в базе данных WordPress. Вы можете увидеть первоначальный смысл во всей его старой славе (вместе с солидными комментариями) здесь (ему уже пять лет, даже — вау).
Как и во всем, что связано с программированием, время идет, вещи совершенствуются и [надеюсь] становятся лучше, чем раньше.
Хотя я по-прежнему использую и рекомендую вариант функции user_can_save (или userCanSave ), я также считаю важным пройти через процесс выделения процесса проверки запроса.
Так что теперь речь идет не только о том, чтобы определить, есть ли у пользователя разрешения, но и о проверке информации о безопасности, поступающей от клиента — будь то через обратную отправку на сервер или запрос, сделанный через Ajax, — и делать это с использованием хороших методов программирования, которые согласовывают как с WordPress, так и с PHP.
Чтобы было ясно, речь идет скорее о безопасной отправке формы WordPress со страницы параметров или страницы настроек, чем, скажем, о форме, полученной из шаблона. Это другой пост в другой раз.
Но, тем не менее, многие из нас работают над созданием приложений на WordPress, и для этого требуется следующее.
Безопасная отправка формы WordPress
В этом посте я не буду вдаваться в подробности определения того, является ли что-то автосохранением или ревизией поста.
Тем не менее, я собираюсь пройтись по процессу использования функции, отвечающей за проверку входящей информации, и сделать это с использованием современного подхода с использованием объектно-ориентированных практик и API-интерфейсов WordPress и функций PHP.
1 Начиная с общего уровня
На базовом уровне предположим, что есть базовый класс, от которого есть другие подклассы, использующие эту функцию. Это говорит нам о том, что нам нужно использовать защищенный модификатор видимости.
Мы также знаем, что будем иметь дело со значением одноразового номера WordPress и связанным с ним действием. Это означает, что сигнатура функции будет выглядеть примерно так :
2 Очистите данные, проверьте одноразовый номер
Что касается всего, что отправляется на сервер, мы знаем, что нам нужно будет проверить, что данные установлены, и если это так, нам нужно будет очистить информацию.
Это означает, что нам понадобятся следующие функции:
И мы также знаем, что нам нужно будет проверить одноразовый номер, поэтому нам также понадобится wp_verify_nonce.
3 Рабочий первый проход
Рабочий первый проход этой функции может выглядеть примерно так:
Но что, если кто-то делится данными, которые отправили запрос POST (а не запрос GET )? Затем мы могли бы изменить функцию, чтобы она выглядела примерно так:
И этого было бы достаточно. Но если мы действительно хотим, чтобы данная функция была как можно более чистой, то мы могли бы разбить ее еще дальше.
4 Функция для каждой цели
Учитывая приведенный выше код, мы знаем, что нам нужно обрабатывать как запросы GET, так и запросы POST. PHP предлагает функцию filter_input, которая полезна, ее легче читать (ну, это субъективно), но она также проходит несколько проверок качества кода.
Кроме того, мы можем использовать простую функцию в стиле фабрики, чтобы разделить логику на отдельные функции, например:
Во-первых, нам нужно написать две отдельные функции — одну для POST-запроса:
И один для запроса GET:
Затем мы можем связать это вместе в исходной функции следующим образом:
Четкое управление входящими запросами
Возможно, это выглядит как сложный способ обработки простого решения, учитывая исходный набор кода, который был общим.
Это, безусловно, возможно, особенно если вы ограничены во времени или не слишком заботитесь о том, чтобы разбить вещи на наименьшие возможные атомарные (или даже проверяемые) компоненты.
Но если вы хотите писать объектно-ориентированный код с высочайшей степенью точности, возможно, этот процесс поможет именно в этом.
Конечно, это только мой процесс. Я не говорю, что это способ, но это способ. И если у вас есть альтернатива, я всегда могу прочитать больше и обсудить ее в Твиттере. 🙂