Оптимальная оценка приоритетов конечной точки RPC?

Я пытаюсь понять, как можно создать безопасную точку входа без загрузки всего WP-стека. Встроенная точка входа AJAX довольно медленная и фактически непригодна для использования на сайтах с большим количеством плагинов. Поэтому я должен что-то написать сам. Я нашел старый кодер под названием «wp_session» . В основном это база для обеспечения моей конечной точки.

В настоящее время я реализован так:

  1. В моем плагине WP-Back-end я запускаю класс wp_session и сохраняю некоторые данные, которые будут использоваться для проверки позже в моей конечной точке.

  2. Как только клиент делает RPC через мою конечную точку, я возвращаю свой «сеансовый экземпляр» и проверяю, что параметры в этом объекте сеанса одобрены; теперь пользователь имеет привилегию, а пока.

  3. В URL-адресе RPC я добавляю «подпись», которая рассчитывается на стороне клиента, используя HMAC_SHA1 и секретный ключ на основе md5 (user_id + пароль пользователя) + wp_nounce (добавляет ограничение по времени) и солевой ключ WordPress ( добавляет соль конкретного участка). Клиент «подписывает» полезную нагрузку с этим токеном. Этот же токен передается клиенту из-за рендеринга плагина (действия). Он не может получить такой токен, не войдя в систему.

  4. В моей конечной точке я проверяю, что подпись, созданная клиентом, правильна и по-прежнему действительна.

  5. Сделайте RPC вещь.

Я все еще не решаюсь чувствовать себя так. Может ли кто-нибудь предложить лучшую практику или просто подтвердить, что этих мер достаточно? Например, wp_nounce – отличный и быстрый способ добавить некоторую защиту для вызовов Ajax, но как только вам нужно включить вызовы RPC для удаленных служб, он не будет работать (например: обмениваться ссылкой на основе RPC). В этом случае я мог бы только создать токен без wp_nounce и убедиться, что md5 (user_id + password hash + site-salt_key) в URL-адресе RPC верен. Это сделало бы трюк, но его время не ограничено. Чтобы сделать ограничение по времени на токен, мне нужно будет хранить вещи в базе данных без WP API, потому что снова из соображений производительности.

Любое предложение приветствуется. Спасибо!

Я думаю, что ваша парадигма не оптимальна. Вы начинаете с предположения о том, что «конечная точка WordPress Ajax медленная», и ваше решение заключается в «создании альтернативной схемы аутентификации». Это полностью создает проблемы.

Любая безопасность должна использоваться как можно больше и кодироваться людьми, специализирующимися на безопасности. Компромисс над переориентацией безопасности ради производительности – это главный красный флаг.

Вернемся к квадрату. Если ваша проблема: «Конечная точка WordPress Ajax медленная», тогда создайте более быструю конечную точку WordPress Ajax. Вы можете сделать это с помощью SHORTINIT (есть ответы об этом на сайте), чтобы иметь очень настраиваемую нагрузку на ядро. Это кошмар, чтобы отправить публичный код и боль при обновлении, но для частного высокопроизводительного Ajax это путь.

PS Я не уверен, как ваши потребности в Ajax связаны с RPC (XML RPC?), Поскольку вы упоминаете оба.