Fi1osof

Если вы нигде не пишите чистые SQL-запросы (или хотя бы для формирования имен таблиц в таких запросах используете $modx->getTableName($class)), то все у вас будет работать нормально.

Воспринимает только числовые идентификаторы. Строчный видимо пытается привести к инту и не получает профиль, редиректит на юзеров.

Перечитайте комментарии.

Вот этого точно вряд ли дождусь)

А вот я так и знал, что скажешь «блин, ну хотел же нормально отдохнуть, выходные же!».

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

Это все слишком сложно.

Видимо задумывалось как возможность, но не доделано.

Если под капот залезть, там много чего можно найти из того, что задумывалось, но не доделалось))

Нифига не проходит joxi.ru/nAyz3VMFX8kDRr

Разве? Насколько я помню, Василий писал, что обновление работает только для префикса modx_.

Это уже у Василия надо спрашивать. Сам MODX при обновлении учитывает префиксы. Более того, даже если взять Vapor, то можно снять снимок, создать новый сайт с кастомным префиксом, накатить на этот сайт созданный пакет, и все таблицы будут созданы и/или обновлены с учетом префикса.

А вырезать из параметров запроса команды sql поможет решить проблему безопасности?

Поможет. Но как отличить опасный запрос от не опасного? К примеру, здесь кто-то захочет найти статьи по запросу «xPDO update», и что ему выдавать? А что делать с запросами uupdatepupdatedupdateaupdatetupdatee? Рекурсивную чистку писать? Короче, это все заморочки лишние.

В MODX параметры запроса фильтруются. Может ужесточить правила и вырезать нахрен слова «insert», «update» и «delete» из запроса?

Я не сторонник совсем все закрывать, так как сам часто пишу сложные не стандартные запросы, а с этим в xPDO итак все сложно, и если на уровне xPDO-запросов все будет закрыто, то это меня не будет радовать. Так что я буду просто менять префиксы.

Для пользователей хостинга modhost.pro вообще ужас ужас. ))

А там в чем проблема? Раз изменить префикс таблиц, потом обновление MODX-а же проходит с учетом префикса.

В xPDO метод обновления таблиц не дописан, так что вряд ли есть возможность при обновлении сайта обновить им таблицы.

Т.е. бежать кругом дистрибутив advanced заливать и менять все и вся…

А что, advanced умеет менять префиксы таблиц на готовом сайте? То есть переименовывать их?

Нет. Я нашел способ без каких-либо прав. Точнее методов значительно больше, чем один, но все они сводятся к необходимости знать названия таблиц (с учетом префиксов).

Всегда пожалуйста!

Проблема действительно есть. Еще утром заметил (до моих каких-то экспериментов), но не стал писать, думал ты итак заметишь. В анонимной сессии: joxi.ru/823OeZKC6ow5V2

ОК.
Подсказываю вариант: создаешь еще один контекст без всяких документов, прав и т.п. Вешаешь плагин на авторизацию веб-пользователя. Если пользователь такой, который должен иметь права на переключение, его в плагине делаешь $modx->addSessionContext($ctx), то есть дополнительно авторизуешь его в этот спецконтекст. А плагин switchUser модифицируешь на проверку авторизован в этом контексте или нет, там посмотришь. Только там еще на контексте проверка есть на право user_save, вот это можешь убрать. Если ты никого в этот контекст не будешь авторизовывать, то дополнительные проверки не потребуются (во всяком случае, если это не публичный компонент). или можешь добавить допправа на этот контекст и их дополнительно проверять.

Не пускай. Дай ссылку на сайт, я сам зайду)))
Шутка на злобу дня :)

Если сможешь модифицировать, может и покупать тогда не надо, если на это хватает знаний. Если вдруг не хватит, то можно подправить с ошибками, а с безопасностью шутки плохи. Ну да ладно, это уже тебе решать.
Я не напрашиваюсь, но все-таки это дело такое.

Есть у меня один клиент крупный (колл-центр), там там довольно много пользователей и групп пользователей, и нужна была возможность без всяких переключений в контекстах делать выборки от разных пользователей, чтобы видеть, какие данные им будут предоставлены. Делалось это вот так:) joxi.ru/v29QeZnHGVj4x2

По твоей задаче: для того, чтобы без лишних танцев с бубнами, была корректная проверка на переключение пользователей, надо все-таки, чтобы пользователь имел авторизацию сразу в двух контекстах. Не думаю, что в ядре компонента этот механизм поменяется, но за +1000 к купленному компоненту я подправлю его на твоем сайте под твои нужды, чтобы он не использовал mgr-контекст.