По случаю проглядываю старый комменты. Андрей, вы довольно близки были к правде, и подобная сборка появилась, хоть и на 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`
]]

можно обойтись и без скрытого поля в каждой форме.
Кроме данных из вашей формы formit передает также [[+pageId]] всегда, как раз идентификатор ресурса, с которого была отправлена форма.
И следовательно уже в шаблоне письма можно сформировать ссылку на этот ресурс — [[~[[*pageId]]]]

Нашел вот такое, вставляем скрытый инпут на странице формы заявки.

<INPUT TYPE="HIDDEN" name="pageurl" VALUE="http://адрес-сайта.ru/[[~[[*id]]]]" /> <!-- с какой страницы //-->

а шаблоне письма вывод [[+pageurl]]

НАШЕЛ! вопрос решен

сделал вот так

<?php
return preg_replace("/[^,.0-9]/", '', substr($input,2));

и в шаблоне просто вывожу так

+7[[+phone:phone]]

Здравствуйте!
Попробуйте так:

$str = '7';
$input = substr_replace($input, $str, 0, 1);
$result = preg_replace("/[^,.0-9]/", '', $input);
return $result;

Спасибо!

Ниже опубликовал кусочек…

снипет phone:

<?php
return preg_replace("/[^,.0-9]/", '', $input);

Вывожу телефон [[+phone:phone]]

выводит +89003451234
нужно +79003451234

Помогите (