Продолжая содержание предыдущего поста, важно также учитывать использование переходных процессов и аутентификации.
Потому что существуют сценарии, в которых пользователи проходят проверку подлинности на сайте (представьте себе область сайта, предназначенную только для участников) или не проходят проверку подлинности на сайте (например, посетители сайта).
Подобные ситуации присутствуют как в блогах, так и на других сайтах и веб-приложениях по всем направлениям.
WordPress Transients и аутентификация
Как мы можем хранить информацию о пользователях для этих пользователей? К счастью, PHP предоставляет нам некоторые функциональные возможности, которые позволяют нам делать это без использования API-интерфейсов WordPress.
В конечном счете, цель, которую мы стремимся достичь, — это сериализация временных данных с использованием ключа, использующего идентификатор пользователя, прошедшего проверку подлинности, или пользователя, не прошедшего проверку подлинности.
И вот как сделать каждый из них.
API-интерфейс WordPress
Предполагая, что пользователь прошел аутентификацию в WordPress, мы можем использовать функцию get_current_user_id. Это тоже просто.
Из Справочника по коду:
Получить идентификатор текущего пользователя
Затем мы можем использовать эту функцию в конструкторе, чтобы установить свойство, в котором хранится идентификатор пользователя. Я сейчас покажу код для этого, но как насчет ситуации, когда пользователь не вошел в систему?
PHP-API
Когда дело доходит до хранения информации о пользователях, которые не прошли проверку подлинности, нам по-прежнему нужен способ их идентификации. Это можно сделать различными способами, используя различные значения, поддерживаемые PHP, для добавления к временному ключу.
Помните, что ключ должен быть уникальным, и пока он уникален для пользователя на сайте, он должен быть хорошим.
Две функции, которые предлагает PHP:
Что касается второго, то он не будет работать с IIS или любыми серверами на базе Windows. Но я упоминаю его здесь как еще одну альтернативу хостам, основанным на *nix (поскольку таковых очень много, особенно в отношении WordPress).
Функция get_current_user достаточно понятна:
Получает имя владельца текущего PHP-скрипта
В инструкции есть еще кое-что, на что следует обратить внимание. В нем явно указано, что «[возвращается] имя владельца текущего PHP-скрипта». И я обращусь к этому в конце поста.
Кроме того, get_current_user также может не соответствовать вашим требованиям, в зависимости от того, как настроен сервер и какой пользователь является «владельцем» PHP-скрипта, работающего на сервере.
Но достаточно сказать, что для этого примера это работает. И вот почему: я пытаюсь продемонстрировать, как использовать значения, уникальные для посетителя, не прошедшего проверку подлинности на сайте, для создания ключа, из которого мы можем извлечь информацию.
То, как генерируется ключ, является вторичным по отношению к фактическому коду.
Объединение всего вместе
Так как же выглядит код, если мы хотим использовать вышеуказанные функции? То есть, если мы поддерживаем свойство, которое содержит идентификатор пользователя, а затем делает это как для аутентифицированных, так и для неаутентифицированных пользователей?
И это даст вам функциональность, необходимую для создания уникального идентификатора пользователя как для пользователей, прошедших проверку подлинности, так и для пользователей, не прошедших проверку подлинности.
Как насчет временных ключей?
Да, частью того, что мы обсуждаем, является также создание уникальных переходных ключей.
Чтобы сделать это, я обнаружил, что достаточно просто объединить идентификатор пользователя, который мы сгенерировали выше, и добавить его к ключу, который используется при сериализации переходного процесса.
Например :
Затем, со значением, которое возвращает эта функция, мы можем использовать его для сохранения данных как переходных процессов с использованием уникальных ключей.
Еще другие варианты
Как уже упоминалось, простое использование функций, встроенных в PHP, может быть неправильным путем. Но это не значит, что нет других значений, которые обеспечивают уникальное значение того, что вам нужно.
В таких случаях важно определить, как вы хотите идентифицировать своего пользователя, какую операционную систему он использует и какая учетная запись пользователя владеет приложением.
Если это не обеспечивает достаточно уникальной настройки (а весьма вероятно, что не будет при определенных условиях), то принцип остается в силе — вам просто нужно заменить функциональный вызов get_current_user() на что-то, что лучше всего подходит для ты.