Fi1osof

Каждый ученик извлекает из урока ровно столько, сколько он может извлечь.

Нам больше делать нечего, как сидеть и гадать на картах Таро, что там автор имел ввиду.

Это одна строчка кода, Карл. Одна. Чего там думать? Я переписывал свой сайт, 400 000 строк изменений, и все ОК. А у вас от одной строчки мозг ломается? Ох, измельчали нынче программисты.

Мы не за зарплату там сидим, есть дела и поважнее.

Так и я не зарплате, если что.

иначе просто закрывают PR

Ну так надо было закрыть и все. ОК, я сам закрыл. И больше ничего не отправлю, даже трогать не буду.

К слову, еще одна причина почему не хочется заниматься кодингом в ядро: я отправил ПР, но видите ли не достаточно хорошо его оформил (точнее совсем не оформил). Почему я должен на это тратить время? Это не issue, где бы я спрашивал «А как мне сделать то-то». Это PR. То есть я потратил не мало своего времени, нашел проблему, пофиксил ее, и еще должен что-то там разжевывать? А мейнтейнеры на что? Это уже не программисты, а менеджеры какие-то. Как будто все это должно мне быть важнее, чем им.

Я в комменте написал.

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

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

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

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

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

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

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

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

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

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

Люто плюсую.

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

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

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

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

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

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

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

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

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

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

Не за что!

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

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

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

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

С Vue я не работаю, и не вижу ссылки на github там. Плюс там еще и SaSS, а я юзаю styled-components. Так что не подойдет, к сожалению.
В любом случае, я буду делать стилистически очень близкую к родной админке (просто потому что на нее буду смотреть), так что перейти не должны быть сложности. Но еще раз отмечу: пока что это только эксперимент. А там сделаем выводы.

Я буду делать админку чисто фронтовую, работающую по API. То есть ей не важно что и как там на бэке работает, чтобы сформировать ответ. Важно только чтобы ответ был ожидаемый. Если в какой-то момент там выпилится xPDO и будет работать как-то иначе — ей не важно, если структура ответов будет все та же.
Но как и сказал Иван, xPDO — это ядро MODX-а. Нельзя его просто так выпилить. Это не только формирование SQL-запросов и работа с БД, но и проверка прав, кеширование и много всего другого.

ОК

Хорошо

Нет, с MODX LLC я связываться не хочу, так как зарекся на всякие там NDA и т.п. Только опенсур в чистом виде Use As Is.

Давай я на днях немного поэкспериментирую и выложу что получится, и напишу какие подводные камни увидел и что мне не нравится. А там посмотрим. Если сообщество будет готово включиться в проект, тогда совместно может и поделаем. Если нет, то нет. Вообще, теоретически это должен быть очень полезный и интересный опыт и возможность лучше узнать MODX изнутри.

А сообщество готово собрать $8000 на такую админку, которая именно в ядро MODX попадет? Или может хотя бы $4000 на стороннее решение на JS/TS (с полной совместимостью MODX, но не со старыми сторонними пакетами на ExtJS)?

Иван, я MODX все еще отлично знаю. Ты это помнишь. MODX вполне позволяет параллельно несколько админок делать. То ничто не мешает сделать manager-2/

И тут два варианта:
1. Делать с использованием старого REST API как есть (то есть чисто интерфейсы).
2. Сразу прикручивать PHP+GraphQL, и тогда вообще АПИ взрослое будет и можно развиваться в сторону современных Headless CMS.