И никак не думал, что сам Джейсон такую засаду сделает :)

Бывает со всеми.

Отправил простенький PR. Лечит проблему.

Я видел. Я же теперь интегратор ) Ну ты хоть в описании опиши. )

Я докопался до проблемы :)
Я конечно же все это проверял, но не достаточно глубоко. Попробовал как должно быть, не сработало, подумал никогда и не было. А оказывается было. Во второй вертке проверяет

$isLogin = $target == 'login' || $target == 'security/login';

а в 3-ей (на которой я и экспериментировал) уже вот так:

$isLogin = $target == 'Login' || $target == 'Security/Login';

Но в коннекторе-то проверяется именно на 'security/login', чтобы выставить define('MODX_REQP', false);

И никак не думал, что сам Джейсон такую засаду сделает :)

Всегда считал его мегаконсервативным в плане изменения кода, а тут фигак и в продакшн.

Отправил простенький PR. Лечит проблему.

MODX под рукой нет.

Теоретически, вот тут определяется константа, которая позволяет пройти твоё блокирующее условие.

Покажи пример запроса. Я action=security/login первым делом проверял. И в статье показывал скриншопы, что без кукиса даже из админки через модалку не залогиниться. Вот здесь отбивает же запрос.

Хотя 401 означает — требуется аутентификация, а код для отсутствия прав — 403.

Люто плюсую.

нет средств проверить авторизован ты или нет

Такого API нет.

Но проблема тут в том, что у нас неоднозначная система доступов, и легко могут быть случаи, когда интерфейс загружен, а на определенный запрос нет прав.

Я по этому поводу уже говорил, что в MODX нет корректного кода ответа — на все действия он отвечает кодом 401. Хотя 401 означает — требуется аутентификация, а код для отсутствия прав — 403.

По случаю проглядываю старый комменты. Андрей, вы довольно близки были к правде, и подобная сборка появилась, хоть и на Next+React, а не на Nuxt+Vue: github.com/prisma-cms/nextjs

На нем вот и небольшой эксперимент с MODX-админкой делался: modx.pro/development/21732

Я в курсе этого механизма. Поэтому и говорю, его оставить, через него залогиниться, а дальше работать со своей реализацией. Но у тебя будет и токен и куки.

Кстати, чтобы не блокировало, нужно передать в форме action = «security/login».

Я его взял потому что довольно хорошо знаю его, и знаю, что роутинг на файлах для него — совсем не обязательная штука. К примеру вот этот роутер обрабатывает вообще все УРЛы, который не попали в логику явного роутинга, и в зависимости от типа ресурса я выдаю ту или иную конечную вьюху. И да, это MODX-ресурсы, берущиеся из таблицы site_content, только уже не средствами MODX (но это не особо важно).

А вот здесь и вовсе прописана обработка входящих запросов еще до вызова некста. Так что некст — это следствие, а не причина.

А некст я взял, потому что посмотрев имеющиеся решения на рынке, он больше всего понравился своей относительной минималистичностью и гибкостью в кастомизации.

Либо я тебя не понимаю, либо ты меня. Я выше писал, что одного только токена не достаточно, нужен еще и кукис (во всяком случае для обращения к MODX). Во-вторых, сам этот токен получить — не просто так.

Еще и по сути нет средств проверить авторизован ты или нет, то есть нет метода типа Security/User/GetCurrentUser. В чем проблема здесь? В том, чтобы понять когда ты авторизован, а когда нет. Единственный вариант тут — это просто реагировать на 401-ые ошибки (как это сейчас MODX делает). Но проблема тут в том, что у нас неоднозначная система доступов, и легко могут быть случаи, когда интерфейс загружен, а на определенный запрос нет прав. То есть ты запросил что-то, а в ответ получил 401-ый код серверный (что MODX делает много где) и это одновременно может быть признаком того, что ты не авторизован, хотя не гарантирует это (ты на самом деле авторизован, но нет прав на этот запрос и получил 401). В общем, все это делает работу с API неудобной и неоднозначной.

П.С. На странице админки для действия «security/login» блокировки вроде нет.

Проверь сам. Я ссылку на кусок кода дал, там блокируются вообще все запросы на коннектор, если пользователь не авторизован. А авторизация в админку работает через обычную форму с POST-запросом на саму страницу, а не через Ajax-запрос, и авторизация выполняется на уровне контроллера самой админки, а не через коннектор. При заходе на страницу админки, ответ обрабатывается через modManagerResponse, и если пользователь не авторизован, то вызывается контроллер security/login, и если отправляются данные авторизации, срабатывает handleLogin(), и там уже вызывается процессор Security/Login. То есть этот механизм не через коннекторы работает.

Как заготовка — прикольно, но для админки, на мой взгляд, NextJS лишний, тем более со своим файловым роутингом, который на больших проектах заставляет страдать.
Ты взял NextJS потому что привык и удобно, либо из-за какой-то его конкретной фичи?

Так наоборот вроде проще. Нажал «Войти», загрузилась SPA страница с токеном и работой на здоровье.

Да не, можно. Но это как-то ненадежно. Хотелось бы поменьше костылей.

А почему нельзя для аутентификации использовать текущий подход с редиректом? Я понимаю про всякие приложения — нужен нормальный вариант через REST. Но тут же речь про админку.

П.С. На странице админки для действия «security/login» блокировки вроде нет.

Не за что!

Про авторизацию частично обсуждалось modx.pro/howto/18977#comment-114090, видимо, многие спотыкаются :)

Нее, там совсем чуть-чуть и вообще про REST-контроллеры. Я же хотел заюзать нативные средства без каких-то движений на стороне кода сайта. Уточню разницу: РЕСТ-контроллер, это всего-лишь общий класс на чтение данных и отдачу ответа. То есть да, в нем есть возможность добавить логику, всякие вещи дописать и все, но все это на уровне кастомных контроллеров. Но если смотреть имеющиеся системные процессоры, то там много всякой логики, особенно на создание/редактирование всяких объектов (включая пользователей, ресурсы и т.п.). Гляньте хотя бы тот же процессор создания ресурса, который в том числе обрабатывает логику с ТВшками, группами ресурсов и т.д. и т.п. А еще в этих процессорах уже прописана проверка всяких прав. Переписывать все это на уровне кастомных контроллеров — дикий оверхед. Задача же была написать панель, которая не требует никаких лишних движений на стороне кода сайта, при этом максимально поддерживала бы базовые функции, да еще можно было бы что-то свое докрутить. По-хорошему в MODX на уровне ядра надо поправить возможность авторизацию без проверки уже имеющейся, а не как сейчас. Для особых параноиков можно системную настройку сделать, чтобы можно было это блокировать. Ну и текущего пользователя возможность получать. Тогда будет вообще ОК.

Это, кстати, частично исправлено в текущей админке MODX 3, можно в системных настройках увидеть.

Какая именно? Не нашел.

Спасибо за статью и потраченное время!
Про авторизацию частично обсуждалось modx.pro/howto/18977#comment-114090, видимо, многие спотыкаются :)

Помните эту частую проблему, когда указал условия поиска, нашел, что хотел, перешел в редактирование, вернулся назад, а там опять список без условий поиска?

Это, кстати, частично исправлено в текущей админке MODX 3, можно в системных настройках увидеть.

Поддержу, очень не хватает «связки» SeoFilter + Polylang, а также mvtSeoData + Polylang!

Ну не должно такого быть, чтобы не передавался pageId.
Укажите в вашем вызове несуществующее имя чанка для emailTpl
В таком случае на почту придет просто массив с данными и вы увидите, что среди них есть идентификатор ресурса отправителя.

[[~[[*pageId]]]] у меня не передает.

[[!AjaxForm?
    &snippet=`FormIt`
    &form=`contactFormTpl`
    &hooks=`spam,email,FormItSaveForm`
    &emailTpl=`contactEmailTpl`
    &emailSubject=`[[++site_name]]`
    
    &emailTo=`[[++emailsender]]`
    &emailFrom=`noreply@site.ru`
    &formName=`Сообщение с сайта [[++site_name]]`
    &validate=`phone:required,user:blank,username:blank,captcha:blank`
]]