Если вы нигде не пишите чистые SQL-запросы (или хотя бы для формирования имен таблиц в таких запросах используете $modx->getTableName($class)), то все у вас будет работать нормально.
Разве? Насколько я помню, Василий писал, что обновление работает только для префикса modx_.
Это уже у Василия надо спрашивать. Сам MODX при обновлении учитывает префиксы. Более того, даже если взять Vapor, то можно снять снимок, создать новый сайт с кастомным префиксом, накатить на этот сайт созданный пакет, и все таблицы будут созданы и/или обновлены с учетом префикса.
А вырезать из параметров запроса команды sql поможет решить проблему безопасности?
Поможет. Но как отличить опасный запрос от не опасного? К примеру, здесь кто-то захочет найти статьи по запросу «xPDO update», и что ему выдавать? А что делать с запросами uupdatepupdatedupdateaupdatetupdatee? Рекурсивную чистку писать? Короче, это все заморочки лишние.
В MODX параметры запроса фильтруются. Может ужесточить правила и вырезать нахрен слова «insert», «update» и «delete» из запроса?
Я не сторонник совсем все закрывать, так как сам часто пишу сложные не стандартные запросы, а с этим в xPDO итак все сложно, и если на уровне xPDO-запросов все будет закрыто, то это меня не будет радовать. Так что я буду просто менять префиксы.
Нет. Я нашел способ без каких-либо прав. Точнее методов значительно больше, чем один, но все они сводятся к необходимости знать названия таблиц (с учетом префиксов).
Проблема действительно есть. Еще утром заметил (до моих каких-то экспериментов), но не стал писать, думал ты итак заметишь. В анонимной сессии: joxi.ru/823OeZKC6ow5V2
ОК.
Подсказываю вариант: создаешь еще один контекст без всяких документов, прав и т.п. Вешаешь плагин на авторизацию веб-пользователя. Если пользователь такой, который должен иметь права на переключение, его в плагине делаешь $modx->addSessionContext($ctx), то есть дополнительно авторизуешь его в этот спецконтекст. А плагин switchUser модифицируешь на проверку авторизован в этом контексте или нет, там посмотришь. Только там еще на контексте проверка есть на право user_save, вот это можешь убрать. Если ты никого в этот контекст не будешь авторизовывать, то дополнительные проверки не потребуются (во всяком случае, если это не публичный компонент). или можешь добавить допправа на этот контекст и их дополнительно проверять.
Не пускай. Дай ссылку на сайт, я сам зайду)))
Шутка на злобу дня :)
Если сможешь модифицировать, может и покупать тогда не надо, если на это хватает знаний. Если вдруг не хватит, то можно подправить с ошибками, а с безопасностью шутки плохи. Ну да ладно, это уже тебе решать.
Я не напрашиваюсь, но все-таки это дело такое.
Есть у меня один клиент крупный (колл-центр), там там довольно много пользователей и групп пользователей, и нужна была возможность без всяких переключений в контекстах делать выборки от разных пользователей, чтобы видеть, какие данные им будут предоставлены. Делалось это вот так:) joxi.ru/v29QeZnHGVj4x2
По твоей задаче: для того, чтобы без лишних танцев с бубнами, была корректная проверка на переключение пользователей, надо все-таки, чтобы пользователь имел авторизацию сразу в двух контекстах. Не думаю, что в ядре компонента этот механизм поменяется, но за +1000 к купленному компоненту я подправлю его на твоем сайте под твои нужды, чтобы он не использовал mgr-контекст.
Поможет. Но как отличить опасный запрос от не опасного? К примеру, здесь кто-то захочет найти статьи по запросу «xPDO update», и что ему выдавать? А что делать с запросами uupdatepupdatedupdateaupdatetupdatee? Рекурсивную чистку писать? Короче, это все заморочки лишние.
Подсказываю вариант: создаешь еще один контекст без всяких документов, прав и т.п. Вешаешь плагин на авторизацию веб-пользователя. Если пользователь такой, который должен иметь права на переключение, его в плагине делаешь $modx->addSessionContext($ctx), то есть дополнительно авторизуешь его в этот спецконтекст. А плагин switchUser модифицируешь на проверку авторизован в этом контексте или нет, там посмотришь. Только там еще на контексте проверка есть на право user_save, вот это можешь убрать. Если ты никого в этот контекст не будешь авторизовывать, то дополнительные проверки не потребуются (во всяком случае, если это не публичный компонент). или можешь добавить допправа на этот контекст и их дополнительно проверять.
Шутка на злобу дня :)
Если сможешь модифицировать, может и покупать тогда не надо, если на это хватает знаний. Если вдруг не хватит, то можно подправить с ошибками, а с безопасностью шутки плохи. Ну да ладно, это уже тебе решать.
Я не напрашиваюсь, но все-таки это дело такое.
По твоей задаче: для того, чтобы без лишних танцев с бубнами, была корректная проверка на переключение пользователей, надо все-таки, чтобы пользователь имел авторизацию сразу в двух контекстах. Не думаю, что в ядре компонента этот механизм поменяется, но за +1000 к купленному компоненту я подправлю его на твоем сайте под твои нужды, чтобы он не использовал mgr-контекст.