Альфа релиз альтернативной админки для MODX

Всем привет!

В продолжение недавней дискуссии публикую то, что удалось сделать за два дня (точнее за 23 часа).





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

Первое, что хотелось бы отметить, что MODX потенциально имеет API (Здесь и далее, говоря про API MODX, я буду иметь ввиду коннекторы и процессоры), чтобы можно было с админкой работать со стороны, но все же есть недочеты. Первый, который меня нормально так удивил и затребовал несколько часов на решение — это невозможность авторизоваться по API. То есть так-то есть процессор Security/Login, но проблема в том, что вызов любого коннектора блочится на уровне проверки доступов по кукису и токену, отдавая 401, если доступа нет. То есть получается замкнутый круг: вы не можете авторизоваться, потому что не авторизованы и процессор авторизации не может быть вызван. Если вы смеетесь, то зря. Наверняка же все сталкивались с появлением такого окошка:


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


— Видишь окно авторизации
— Да
— А его нет…

А сессия может быть завершена не только по вашей инициативе, ведь кто-то может в админке нажать «Завершить все сеансы».

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

В таком случае конечно же можно было создать свой собственный коннектор с указанием глобальной define('MODX_REQP', false) и тогда все ОК было бы, но мне интересно-то было сделать авторизацию без модификаций. И пришлось поизвращаться. Пришлось слать POST-запрос с данными авторизации на страницу самой админки (а не коннектор) и в ответе искать токен (а так же кукис в заголовках). И тут еще два подводных камня возникло: во-первых, MODX в любом случае при авторизации шлет в ответе данные редиректа. fetch по-умолчанию следует этим редиректам (то есть делает следующий запрос, следуя указанному правилу редиректа), и ответ содержит самые последние данные. При этом он не отправляет полученные кукисы (ну, потому что второй запрос-то не содержит в себе данных формы). Пришлось запретить ему это. Во-вторых, оказывается, MODX не имеет коннектора для возврата данных авторизованного пользователя. То есть если ты авторизован и хочешь получить свои данные, это можно сделать только через общий процессор получения данных пользователя и только с указанием id пользователя. То есть если ты не знаешь свой id, ты не можешь запросить свои данные. MODX конечно знает кто ты (ну, ты же авторизован), но он тебе ничего не скажет. В общем, пришлось где-то искать этот id, и найти его получилось на странице профиля пользователя, то есть /manager/?a=security/profile. Там в недрах можно найти небольшой кусочек JS-кода, в котором имеется user: $id (хотя это на самом деле было лишнее, потому что на всех страницах админки итак есть глобальный объект MODx.user). Проблема только в том, что эта страница легко может быть запрещена пользователю (есть такое правило в MODX). И получается, что если у пользователя нет доступа к этой странице, я не смогу получить его id и соответственно его объект. Очень не круто.

В общем, авторизация оказалась тем еще квестом, но ее получилось условно победить. Далее уже стоял вопрос непосредственно получать данные и выводить их в админке. И тут (при наличии авторизации) особых проблем нет. Но все же тоже не идеально. Чем же я не доволен?

Во-первых, с API приходится работать практически вслепую. То есть не ясно что можно запросить и что будет получено. Для сравнения, вот мое API:


Могу и общую схему изучить


Я четко понимаю какие методы есть, что я должен/могу передать, что могу получить.

В MODX мне все это неведомо. Приходится лезть в код и смотреть что там можно сделать. И комментарии к методам не особо помогают. К примеру, вот процессор получения списка пользователей. В нем написано:

/**
 * Gets a list of users
 * @param string $username (optional) Will filter the grid by searching for this username
 * @param integer $start (optional) The record to start at. Defaults to 0.
 * @param integer $limit (optional) The number of records to limit to. Defaults to 10.
 * @param string $sort (optional) The column to sort by. Defaults to name.
 * @param string $dir (optional) The direction of the sort. Defaults to ASC.
 * @package MODX\Revolution\Processors\Security\User
 */

То есть по идее это параметры, который в него можно передать в запросе. Здесь что-нибудь есть про параметр query? Нет. А он есть. При чем можно передавать не просто строку, но и разделенную знаком двоеточия (первая часть будет названием колонки в профиле (именно в профиле пользователя, а не в самом пользователе), а вторая — искомая подстрока).

Вот пример простого поиска:


Вот по fullname:


Вот по email:


А вот по username:


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

К слову, кто у в безопасность шибко шарит? Вот здесь не видно вообще никаких средств по валидации/санитации запроса:

$c->where([
                    $c->getAlias() . '.username:LIKE' => '%' . $query . '%',
                    'Profile.fullname:LIKE' => '%' . $query . '%',
                    'Profile.email:LIKE' => '%' . $query . '%'
                ], xPDOQuery::SQL_OR);

Я знаю, что зами POST-запросы вроде как дополнительно санитайзятся немного, но вряд ли там все случаи закрываются.

Второе, что не удобно: совершенно не ясно с типизацией. То есть я не знаю истинную структуру ответа, не знаю набор возвращаемых полей. Сейчас опытным путем получилось выяснить, что в списке пользователей вот такие поля возвращаются:

{
      id: 10,
      username: 'tyjtyjty',
      class_key: 'modUser',
      active: false,
      remote_key: null,
      remote_data: null,
      hash_class: 'MODX\\Revolution\\Hashing\\modNative',
      primary_group: 0,
      session_stale: null,
      sudo: false,
      createdon: '2021-04-10 16:46:13',
      fullname: '',
      email: 'fdfsdf@localhost',
      blocked: false,
      cls: 'pupdate premove pcopy'
    }

А при запросе конкретного пользователя вот такие:

{
    id: 10,
    internalKey: 10,
    fullname: '',
    email: 'fdfsdf@localhost',
    phone: '',
    mobilephone: '',
    blocked: false,
    blockeduntil: '',
    blockedafter: '',
    logincount: 0,
    lastlogin: '',
    thislogin: 0,
    failedlogincount: 0,
    sessionid: '',
    dob: '',
    gender: 0,
    address: '',
    country: '',
    city: '',
    state: '',
    zip: '',
    fax: '',
    photo: '',
    comment: '',
    website: '',
    extended: [],
    username: 'tyjtyjty',
    class_key: 'modUser',
    active: false,
    remote_key: null,
    remote_data: null,
    hash_class: 'MODX\\Revolution\\Hashing\\modNative',
    salt: 'some_salt',
    primary_group: 0,
    session_stale: null,
    sudo: false,
    createdon: '2021-04-10 16:46:13'
  }

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

В общем, не очень удобно со всем этим работать. Тем не менее, первый камень заложен, и если сообществу будет интересно, можно будет совместно продолжить этот эксперимент. Проект я выложил здесь: https://github.com/Fi1osof/modx-next-manager

Если на вашем компьютере нет node-js и вы вообще с таким не работаете, но хочется посмотреть это все в работе, можно сделать через https://vercel.com. Вот шаги:

1. Регаемся на github.com, если там нет еще аккаунта.
2. Клонируем к себе проект github.com/Fi1osof/modx-next-manager (справа вверху есть кнопочка Fork).
3. Регистрируемся а https://vercel.com, лучше всего через тот же github.com
4. В ЛК жмем New Project.


5. Находим свой склонированный проект


6. Выбираем вариант «Персональный аккаунт». Это тогда будет бесплатно. Команду не надо создавать.


7. Создаем в переменных окружения SITE_URL со ссылкой на ваш сайт (запросы никак не логируются и мне ничего доступно не будет, так что не беспокойтесь, проект ваш и создается в вашем профиле).


По умолчанию в запросах будут использоваться manager/ и connectors/. Если на вашем сайте эти разделы изменены, укажите тогда явно тут же переменные MANAGER_URL и CONNECTORS_URL (полностью, включая домен/раздел/ (слеш на конце обязателен)).

Жмем deploy. Пойдет процесс.


Если все ОК, то появится панель проекта.


Когда все соберется и запустится, переходите по ссылке из проекта и пробуйте свой логин/пароль. Если что будет не так, пишите в комментах.

Ну а для тех, кто хочет локально попробовать, да еще и с кодом поиграться, все относительно просто:

1. Клонируем себе проект
git clone github.com/Fi1osof/modx-next-manager
cd modx-next-manager

2. Создаем файл переменных окружения и редактируем его (Там надо указать адрес MODX-сайта, лучше локального, если есть запущенный на компе).
cp .env.sample .env

3. Устанавливаем зависимости
yarn install

4. Запускаем проект
yarn dev

По умолчанию будет работать на localhost:3000. Можно изменить порт PORT=3333 yarn dev

По адресу localhost:3000/api будет доступен GraphQL Playground, чтобы писать GraphQL-запросы. Сейчас вот эти в помощь:

query me {
  me (
    where:{
      id: 1
    }
  ){
    ...user
  }
}

query user {
  user (
    where: {
      id: 10
    }
  ){
    ...user
  }
}

query usersConnection {
  usersConnection (
    start: 0
    limit: 10
    where:{
      # query: "test"
    },
  ){
    total
    users {
    	...user
    }
  }
}

mutation signin {
  signin (
    username: "username"
    password: "password"
  ) {
    token
    userId
  }
}


fragment user on User {
  id
  username
  fullname
  email
  active
  blocked
  createdon
  cls
}

Только в настройки надо зайти и изменить «request.credentials»: «omit» на «request.credentials»: «same-origin» (Не забываем сохранить настройки). Это чтобы в запросах кукисы отправлялись.



При успешном выполнении запроса авторизации signin, в ответ вы получите токен. Его надо указать в заголовки Authorization, чтобы выполнять авторизованные запросы.


Если кто вообще захочет углубиться во все это, вот есть двухчасовое обзорное видео по используемому движку: https://www.youtube.com/watch?v=1gaLnlbaGG8. Скучновато и затянуто, но зато почти все необходимое показано и рассказано.

Какие возможны пути развития? Сам я не хочу делать полноценную админку на замену текущей. Тем не менее здесь есть интересные моменты. К примеру, при изменении фильтра в списке пользователей, меняется и УРЛ. Помните эту частую проблему, когда указал условия поиска, нашел, что хотел, перешел в редактирование, вернулся назад, а там опять список без условий поиска? Вот тут такого нет. Даже можно страницу обновить. Во-вторых, все работает без перезагрузки страниц, а не так, как в классической панели, когда любой переход — обновление всей панели, и спасение только в быстрых действиях (типа Быстро обновить). Но вы быстрых действиях панели не полные, да еще и приходится два интерфейса под одну сущность тянуть. Вот тут тоже этой проблемы нет. В третьих, в классической панели при сохранении новой сущности опять-таки происходит обновление страницы, что тоже не круто. И еще ряд моментов, которые можно обыграть гораздо лучше. И хотя я не сделал страницу редактирования/создания пользователя/ресурса и т.п., это очень даже можно сделать, методики отработанные. Просто итак два дня потратил, а еще не ясно нужно все это кому или нет. К слову, тут еще момент есть, который мне никогда не нравился в MODX: необходимость при обновлении передавать все данные объекта. То есть если вы хотите отредактировать только заголовок документа, вам все равно надо передавать все данные этого документа, в том числе TVшки. Бррр…

Я хочу сказать, что с MODX в том виде, какой он сейчас есть, просто не получится сделать все замысленное. Тем не менее, данную наработку можно использовать и развивать для нестандартных панелей. То есть если у вас есть проект, в котором идет активная работа и требуется своя специфическая панель, вот это вполне можно использовать. Более того, как я писал раньше, у меня есть опыт более тесной интеграцией с базой данных напрямую, и тогда вообще можно писать свои SQL-запросы и в целом работать без MODX как такового. Но и другой вариант: написание компонентов для текущей админки. То есть можно написать интерфейсы, которые будут работать без JS на стороне сервера, а просто как фронт-компоненты, при этому интегрировать их в админку. Будет ряд ограничений, но зато это будет работать полностью нативно и без отдельного гемора с авторизацией.

В общем, вариантов куча. Был бы интерес.

P.S.: страничка проекта с задачами, комментариями и т.п.: https://freecode.academy/office/projects/cknadbc18qelo0730a9bunpn3

Если будет работа над проектом, то ее вполне можно организовать.