Контекст

В процессе работы выяснился важный нюанс MODX-аутентификации: после авторизации пользователя в админке его сессионное состояние добавляется в контекст mgr. Если затем проверять авторизацию именно в контексте web, пользователь там может отсутствовать.

При этом нельзя просто считать пользователя авторизованным по самому факту существования MODX-сессии. В одной и той же физической PHP-сессии MODX допускает разные пользовательские identity для разных контекстов. То есть одна браузерная сессия может содержать, например, одного пользователя в mgr и другого в web.

Это не частный баг, а следствие архитектуры MODX, где authentication state является context-specific. Подробное объяснение см. в концепте:

https://modx.club/concepts/modx-pays-for-rarely-used-complexity

Проблема

Текущая логика авторизации рискует сделать одну из двух ошибок:

1. Проверять только web и ошибочно считать пользователя неавторизованным, хотя он вошёл в Manager (mgr).
2. Проверять только наличие общей MODX-сессии и ошибочно доверять ей без понимания, какой именно пользователь авторизован в нужном контексте.

Оба варианта некорректны.

Цель

Сделать проверку MODX-авторизации однозначной и безопасной: явно учитывать контекст, фактический contextToken и identity пользователя, а не выводить состояние авторизации из косвенных признаков.

Что изучить

• Как именно MODX хранит modx.user.contextTokens в текущей версии проекта.
• Как ведут себя mgr и web при последовательной авторизации разных пользователей в одной браузерной/PHP-сессии.
• Какие API MODX корректно возвращают пользователя для конкретного контекста.
• Что происходит при logout только из одного контекста.
• Как ведёт себя session state после обновления permissions/cache и перелогина.
• Нужна ли приложению авторизация именно в web, именно в mgr или достаточно явно выбранного доверенного контекста.

Что сделать

• Убрать логику, которая считает пользователя авторизованным только по факту существования MODX-сессии.
• Явно определять, в каком контексте должна выполняться проверка для конкретного сценария.
• Получать identity/token пользователя именно для нужного контекста.
• Если бизнес-логика допускает авторизацию через Manager, явно обработать mgr как отдельный валидный источник identity, а не пытаться найти того же пользователя в web.
• Не предполагать, что mgr-пользователь и web-пользователь в одной сессии совпадают.
• При необходимости добавить проверку соответствия user id/identity ожидаемому сценарию.
• Корректно обрабатывать отсутствие token для нужного контекста.
• Добавить диагностируемое поведение для неоднозначных состояний, когда в mgr и web присутствуют разные пользователи.

Сценарии для проверки

1. Пользователь авторизован только в mgr.
2. Пользователь авторизован только в web.
3. Один и тот же пользователь авторизован и в mgr, и в web.
4. В mgr и web авторизованы разные пользователи в рамках одной PHP-сессии.
5. Пользователь вышел из web, но остался в mgr.
6. Пользователь вышел из mgr, но остался в web.
7. В сессии есть устаревший/невалидный token.
8. После сброса permissions/cache состояние пользователя меняется или требует перелогина.

Результат

Авторизация определяется по явному состоянию нужного MODX-контекста и конкретной identity пользователя. Наличие общей браузерной/PHP-сессии больше не трактуется как достаточное доказательство авторизации.

Критерии готовности

• Проверка корректно различает mgr и web.
• Поддерживается сценарий, когда Manager-пользователь авторизован только в mgr.
• Разные пользователи в mgr и web не смешиваются.
• Нет доверия к сессии без проверки context-specific identity/token.
• Все перечисленные сценарии покрыты тестами или воспроизводимыми проверками.
• Поведение документировано так, чтобы следующий разработчик не считал MODX-сессию единым глобальным состоянием пользователя.

Архитектурная справка

В MODX контекст — это не только набор настроек, но и часть security/authentication state. В одной физической сессии modx.user.contextTokens может содержать разные user id для mgr и web. Это фундаментальная особенность платформы, а не исключение конкретного проекта.

Источник: https://modx.club/concepts/modx-pays-for-rarely-used-complexity