Fi1osof

Подобные проверки не очень информативны. Проверка идет сразу и наличия кода и имени файла. Если что-то не соблюдается, запись в файл не выполняется, при этом на клиент вернется ответ Успешно. Здесь сразу несколько сценариев с логическими ошибками. К примеру, я сохраняю файл, но по какой-то причине у меня данные кода на сервер не отправились (не важно какие). Сервер мне вернет Успех, я радостный закрываю браузер, потом возвращаюсь к коду через пару дней и начинаю приунывать.
Сценарий второй: я что-то там накодил, а потом решил все затереть, дабы никто из напарников не увидел мой быдлокод. Стераю код и отправляю Сохранить. Опять-таки получаю Успех и закрываю браузер. А потом тот же Сергей Прохоров обнаруживаем мой не затертый файл и начинает тыкать в меня пальцем.

И еще момент: вот отсутствие кода в запросе не всегда следует расценивать как ошибку (может я хочу стереть все в файл). Возвращать ошибочный ответ здесь нельзя. При этом и не записывать в файл здесь нельзя.
А вот отсутствие названия файла — конкретная ошибка, и в данном случае следует возвращать сообщение об ошибке.

Пока не обязательно. Этот компонент изначально ориентирован только на sudo-юзеров, потому прописывать можно любые права — все будет разрешено судошникам. Главное тут — чтобы остальным было запрещено.

Вот так безопасно: github.com/sergant210/modx-console/pull/2/files
А ограничивать только текущей директорией, это, во-первых, не добавляет безопасности, во-вторых, ограничивает функционал (может я хочу поредактировать статический сниппет какого-нибудь стороннего модуля).

Не за что!

А так как файлы сохраняются в директорию core и доступ снаружи туда закрыт, то посчитал, что это безопасно.

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

В помощь кандидатам: SQL-запросы для переноса данных из Эво в Рево. gist.github.com/Fi1osof/b54b347fc739b405def1
Переносит документы, шаблоны и ТВ-шки. Чанки и сниппеты уже вручную переносятся (потому что все равно на Рево все это переписывать придется).

Он не верный. А формулировка «Оказалось, что в документации просто в строке с указанием кодировки был лишний дефис» не особо проливает свет. Правильный ответ: «Там ошибка. Должно быть $charset = 'utf8';, а не $charset = 'utf-8'; ».

P.S.

А формулировка «Оказалось, что в документации просто в строке с указанием кодировки был лишний дефис» не особо проливает свет.

Просто код воспринимается проще, чем обычный текст))) Хотя и указано в комментарии «с указанием кодировки».

Сергей, пробежался я по коду быстренько. Первое, что кидается в глаза — это отсутствие проверки прав при сохранении файлов в процессоре. Это меганесекурно. Любой, залогиненный в админке, сможет записать свой исполняемый код. Это я поправлю.

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

Сергей, спасибо за пулл-реквест. Сегодня ближе к вечеру погоняю и скорее всего одобрю.

Да, можно и так. Можно еще дальше пойти — прописать свой класс на замену modRequest и там рулить права. То есть на основе той же твшки можно еще в своем реквестере отдать 404 (отправить в OnPageNotFound) и там на уровне плагина еще разрулить ситуацию. Но все это не очень будет работать на уровне $modx->getObject($class). А описанное мной выше как раз на этом уровне работает.

Ну, это было мое личное мнение. Я его обосновал. А каждый будет считать как ему больше нравится.

ИМХО — зря заминусовали. Вопрос-то стоял «как сделать доступ к определенной странице сайта одному единственному пользователю». С одной стороны да — ответили. Через группу и т.п. С другой стороны, это вопрос, который действительно касается слабой и темной стороны MODX-а — предоставление прав конкретным пользователям. Представьте, что вы запускаете социалку на MODX, где пользователи могут писать свои топики и предоставлять права каким-то отдельным друзьям. Сейчас, если пытаться такое реализовать, придется плодить 100500 групп пользователей. Потому что в MODX нет механизма предоставления прав на что-либо конкретно пользователям. Есть предоставление прав группам пользователей на группы ресурсов и т.п. А уже потом разбираться к каким группам относятся пользователи и документы. Это не есть гуд. И это действительно запутанно. Так же в MODX нет такого понятия как owner (то есть владелец сущности). На мой взгляд это тоже было бы правильно учитывать. Если я создатель какой-то сущности — значит я имею на нее все права. Это по логике. Но на практике такого нет.

В свое время я заморочился допиливанием механизма политик MODX-а, чтобы учитывались индивидуальные права пользователей, без необходимости добавления ресурсов и пользователей в группы. То есть можно было давать права как отдельным людям, так и отдельным группам. Конечно же пришлось использовать CRC. Если кому интересно, вот некоторые коды:
modzilla.class.php — основной класс модуля
modzillaproject.class.php CRC Проект
modzillaaccess.class.php кастомный класс политик безопасности.
modzillaaccessprojects.class.php что-то там тоже с правами связанное.

Писалось все это очень давно, так что в деталях многого не помню уже. Но это работало. По этому вопросу материал в помощь:
modxclub.ru/blog/dokumentatsiya-dlya-spetsialistov/26.html
modxclub.ru/blog/dokumentatsiya-dlya-spetsialistov/28.html
modxclub.ru/blog/113.html

Материал крайне мозговыносящий, но самый сок. Так что если освоите, понимать будете очень многое.

Поступил переводот Andreas Wettainen aka mrhaw. Большое ему спасибо за это! Отправил PR. Райну написал. Надеюсь скоро примут и опубликуют.

Нужно. Отправляйте PR. Никто не мешает.

Продолжение: modx.pro/development/6346-features-of-the-method-xpdoobjectsave-transaction/

Как правильно ниже написал Всеволод

Дико извиняюсь! Воеводский Михаил. Бывают у меня сбои с именами.
И получается, что он уже выше со своим комментарием.

Ниже ответил на часть ваших вопросов.

Ну и раз уж тема зашла, — там от авторов ничего не слышно по поводу поддержки innodb в modx 3?)

Вряд ли что-то будет. Мы как-то с Джейсоном Ковардом разговаривали, и он выразил свое мнение, что innoDB переоценены, и что он не видит в них особого смысла. Есть там еще один момент важный, о котором я сейчас напишу в отдельной статье. Этот момент очень сильно мешает использованию innoDB, но у нас с Сергеем Прохоровым уже есть ответ на это счет, который вполне возможно будет отправлен в ядро, если Джейсон примет.

Алексей, чтобы вы понимали, Сергей работает со мной не первый год, и его статьи бессмысленными называть то же самое, что и мои.

MyISAM не поддерживает транзакций. И php никаким образом не может заставить эти транзакции работать, потому что это уровень базы данных — если мускул не умеет, то php тут бессилен

Как правильно выше написал Михаил — надо просто переключить таблицы в innoDB, и транзакции заработают.

Вызов функций $modx->beginTransaction(), $modx->commit() и $modx->rollBack() не даёт ровным счётом ничего, ибо это просто обёртки над стандартными одноимёнными функциями встроенного в php PDO-класса.

Вызов этих функций именно то и дает, что выполняет SQL-запросы в текущей сессии на старт транзакций и т.п., ибо как и с другими запросами на это требуется авторизация на MySQL-сервере, обращение к БД и т.п. За это xPDO (в качестве PDO-обертки и отвечает, ибо подсасывает указанные в конфиги настройки соединения и т.п.).

Как мы выяснили выше, xPDO умеет работать только с MyISAM.

Где я там говорил, что xPDO не умеет работать с innoDB??? Я сказал, что есть один локальный баг. Но метод xPDO::getIterator() мало где используется, так что вы вполне можете сделать свои innoDB-таблицы и просто не вызывать в работе с ними этот метод. В остальном все работает.
И еще раз: описанное Сергеем — это не домыслы, а длительная и конкретная практика на крупном и очень сложном проекте. И я тоже использовал транзакции на отдельных проектах, ибо иногда без них просто никуда.

Мне реально некогда красотой заниматься (лексиконы там прописывать и т.п.). Поэтому и выложил так код отдельно. Может кто причешет да отправит PR. Если кто отправит, маякните здесь, я Райну напишу чтобы по возможности быстрее накатили.

На самом деле предложенный багфикс вполне может спасти вашу работу. gist.github.com/Fi1osof/ff3ea018841b1bb1f99b
Обновите этот класс и все. Других ошибок я не обнаружил. Так же при наличии файла core/model/modx/processors/element/propertyset/update.class.php (если вы обновлялись, а не устанавливали с нуля, должен присутствовать), можно просто удалить файл core/model/modx/processors/element/propertyset/updatefromelement.class.php, все должно работать.