Реализация выполнена

Кнопка быстрого редактирования товара и административный toolbar реализованы.

Как сделана проверка авторизации

Изначально рассматривался вариант передавать MODX-cookie в сам MODX-сайт и получать от него результат проверки текущей сессии через его собственные механизмы авторизации.

От этого варианта отказались как от избыточного для текущей задачи: он потребовал бы дополнительной конфигурации окружения, знания адреса MODX-сайта и ещё одного сетевого взаимодействия.

В текущей реализации cookie берётся из заголовков входящего запроса и проверяется напрямую через уже существующий клиент к актуальной базе данных.

Для нового frontend сейчас не нужен полноценный объект MODX-user. Нужен только надёжный признак того, что административная сессия существует, чтобы показать дополнительный toolbar.

Конечные административные действия всё равно выполняются в MODX Manager. При переходе туда MODX повторно проверяет собственную сессию и права пользователя, поэтому новая проверка на frontend не является конечным security boundary.

Почему выбран такой компромисс

Решение принято по принципу баланса затрат и функциональности:

• используется уже доступный клиент к актуальной базе;
• не вводятся дополнительные environment variables;
• не требуется отдельный запрос в MODX;
• frontend получает только нужный ему boolean-сигнал;
• конечная проверка прав остаётся в MODX Manager;
• функционал предназначен только для администраторов, поэтому возможные проблемы быстро проявятся через обратную связь.

Текущая реализация считается достаточной для задачи. Если административная интеграция между новым frontend и MODX начнёт расширяться, механизм проверки сессии можно будет пересмотреть и вынести в более формализованный auth bridge.

Наблюдения и решение по админскому редактированию товара

Что выяснили

Новая публичная часть HappyBaby работает отдельно от MODX, но MODX остаётся рабочим backend и существующей административной средой.

Для кнопки быстрого редактирования нет смысла строить вторую админку в новом frontend. На первом этапе правильнее использовать существующий MODX Manager и дать администратору быстрый переход к редактированию текущего товара.

Главный технический вопрос оказался не в самой кнопке, а в определении административной авторизации на новом frontend.

Фактически нужная MODX-cookie уже существует и отправляется браузером в запросах нового frontend. Значит дополнительную систему авторизации или синхронизацию MODX-пользователя с базой haih-agent сейчас делать не нужно.

Принятое направление

Добавить отдельный GraphQL-запрос, который возвращает текущего MODX-пользователя на основании существующей MODX-сессии/cookie.

MODX остаётся единственным source of truth для этой авторизации. Пользователь MODX на данном этапе:

• не переносится в базу haih-agent;
• не синхронизируется с обычной моделью User;
• не получает отдельную вторую сессию;
• просто возвращается как внешний текущий MODX-user, если native MODX-сессия валидна.

Если GraphQL возвращает текущего MODX-user, frontend считает посетителя административным пользователем и показывает admin toolbar.

UI

Административное действие лучше не смешивать с покупательскими кнопками карточки товара. Предпочтительный вариант — отдельный reusable admin toolbar / admin action layer, видимый только при наличии текущего MODX-user.

Первое действие toolbar:

• Редактировать товар → открыть соответствующий resource в MODX Manager.

Такой toolbar можно позже переиспользовать для других административных действий и типов страниц без создания новой админки.

Что нужно для реализации

1. Добавить GraphQL query текущего MODX-user по native session/cookie.
2. Возвращать только необходимые frontend-данные пользователя; не встраивать его в локальную User-модель.
3. На frontend запросить текущего MODX-user.
4. При наличии пользователя показывать admin toolbar.
5. Для карточки товара сформировать ссылку на редактирование соответствующего MODX resource.
6. Убедиться, что у товара доступен исходный MODX resource ID; если нет — добавить его в данные товара.

Почему выбран этот вариант

Он использует уже существующую авторизацию и административную систему, не дублирует MODX ACL и не создаёт дополнительный auth-контур ради одной функции. При этом frontend получает минимально необходимый сигнал для административного UI и остаётся слабо связанным с внутренней моделью пользователей MODX.