По твоей задаче: для того, чтобы без лишних танцев с бубнами, была корректная проверка на переключение пользователей, надо все-таки, чтобы пользователь имел авторизацию сразу в двух контекстах. Не думаю, что в ядре компонента этот механизм поменяется, но за +1000 к купленному компоненту я подправлю его на твоем сайте под твои нужды, чтобы он не использовал mgr-контекст.
Поможет. Но как отличить опасный запрос от не опасного? К примеру, здесь кто-то захочет найти статьи по запросу «xPDO update», и что ему выдавать? А что делать с запросами uupdatepupdatedupdateaupdatetupdatee? Рекурсивную чистку писать? Короче, это все заморочки лишние.
Подсказываю вариант: создаешь еще один контекст без всяких документов, прав и т.п. Вешаешь плагин на авторизацию веб-пользователя. Если пользователь такой, который должен иметь права на переключение, его в плагине делаешь $modx->addSessionContext($ctx), то есть дополнительно авторизуешь его в этот спецконтекст. А плагин switchUser модифицируешь на проверку авторизован в этом контексте или нет, там посмотришь. Только там еще на контексте проверка есть на право user_save, вот это можешь убрать. Если ты никого в этот контекст не будешь авторизовывать, то дополнительные проверки не потребуются (во всяком случае, если это не публичный компонент). или можешь добавить допправа на этот контекст и их дополнительно проверять.
Шутка на злобу дня :)
Если сможешь модифицировать, может и покупать тогда не надо, если на это хватает знаний. Если вдруг не хватит, то можно подправить с ошибками, а с безопасностью шутки плохи. Ну да ладно, это уже тебе решать.
Я не напрашиваюсь, но все-таки это дело такое.
По твоей задаче: для того, чтобы без лишних танцев с бубнами, была корректная проверка на переключение пользователей, надо все-таки, чтобы пользователь имел авторизацию сразу в двух контекстах. Не думаю, что в ядре компонента этот механизм поменяется, но за +1000 к купленному компоненту я подправлю его на твоем сайте под твои нужды, чтобы он не использовал mgr-контекст.