fix(mgr): токен в ms3.config — гонка HTTP_MODAUTH на Ext-less Vue-страницах (#544) - #545
Conversation
…#544) Ext-less Vue manager pages fire their first API requests on DOMContentLoaded, before the manager JS populates the MODx.siteId global that request.js used as HTTP_MODAUTH. Those early requests went out tokenless, so the connector rejected them (HTTP 200 body {success:false, message:"Доступ запрещён.", object:{code:401}}), surfacing as intermittent "Доступ запрещён" on orders filters/grid-config while the later list request succeeded (grid filled). #533/#534/#536/#537 exposed the race by dropping the waitForElement guard. Ship the token synchronously in the inline ms3.config block, before the Vue module runs: - manager.class.php: new addVueConfig() helper injects token = getUserToken($contextKey) - customers/notifications/order/orders/settings/utilities: use addVueConfig() - request.js getModAuthToken(): read ms3.config.token first, fall back to MODx.siteId Covers all 6 Ext-less Vue pages. No permission/session change.
Thermo-nuclear reviewВердикт: не approve. Направление фикса верное: один 1. Структурный регресс: второй путь auth жив
После появления канонического источника токена два параллельных правила для Remedy: один хелпер ( 2. Soft-fail пустым
|
Moving the ms3.config emission into the base addVueConfig() helper took the `var ms3` literal out of the page controllers, so the *VueEntryTest smoke guards that grep each controller for it failed. Switch the required pattern to `addVueConfig`, and add a base-controller guard in CustomersNotificationsVueEntryTest asserting controllers/manager.class.php ships `var ms3` + getUserToken (the #544 token injection that must not regress).
2 participants
Fixes #544
Проблема
На Ext-less Vue-страницах админки (после #533/#534/#536/#537) периодически падали config-запросы с «Доступ запрещён» — заметнее всего на Заказах:
orders/filtersиgrid-config/ordersв консоли, при этом сессия жива и список заказов грузится.Причина
getModAuthToken()брал токен только из браузерного глобалаMODx.siteId. СтартовыйPromise.all([loadFilters, loadGridConfig])уходит наDOMContentLoadedраньше, чем менеджерский JS выставитMODx.siteId→ запросы уходят безHTTP_MODAUTH→ MODX-коннектор отклоняет их (HTTP 200, тело{success:false, message:"Доступ запрещён.", object:{code:401}}). Список уходит чуть позже, токен уже есть → 200. Отсюда интермиттентность. #533 обнажил гонку, убравwaitForElement.Диагностика по Network подтвердила: у упавшего
orders/filtersв Payload толькоaction+route(нетHTTP_MODAUTH), а тело —code:401.Решение
Отдать токен синхронно в inline-
ms3.config, до старта Vue-модуля:manager.class.php— новый хелперaddVueConfig(): кладётtoken = $modx->user->getUserToken($contextKey)в конфиг и эмитит<script>var ms3 = { config }</script>;customers/notifications/order/orders/settings/utilities—$this->addHtml('var ms3…')→$this->addVueConfig($config);request.jsgetModAuthToken()— читать сперваms3.config.token, фолбэк наMODx.siteId.Токен присутствует в первом же inline-теге → гонки нет by construction. Покрыты все 6 Ext-less страниц. Права/сессия не затронуты.
Проверка
php -l×7 ✓, ESLint ✓,npm run build✓ (PHPStan не применим —controllers/вне анализа).success:trueсHTTP_MODAUTHв URL. Подтверждено на нескольких перезагрузках (гонка была интермиттентной).