Подобные проверки не очень информативны. Проверка идет сразу и наличия кода и имени файла. Если что-то не соблюдается, запись в файл не выполняется, при этом на клиент вернется ответ Успешно. Здесь сразу несколько сценариев с логическими ошибками. К примеру, я сохраняю файл, но по какой-то причине у меня данные кода на сервер не отправились (не важно какие). Сервер мне вернет Успех, я радостный закрываю браузер, потом возвращаюсь к коду через пару дней и начинаю приунывать.
Сценарий второй: я что-то там накодил, а потом решил все затереть, дабы никто из напарников не увидел мой быдлокод. Стераю код и отправляю Сохранить. Опять-таки получаю Успех и закрываю браузер. А потом тот же Сергей Прохоров обнаруживаем мой не затертый файл и начинает тыкать в меня пальцем.
И еще момент: вот отсутствие кода в запросе не всегда следует расценивать как ошибку (может я хочу стереть все в файл). Возвращать ошибочный ответ здесь нельзя. При этом и не записывать в файл здесь нельзя.
А вот отсутствие названия файла — конкретная ошибка, и в данном случае следует возвращать сообщение об ошибке.
Пока не обязательно. Этот компонент изначально ориентирован только на 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 что-то там тоже с правами связанное.
Ну и раз уж тема зашла, — там от авторов ничего не слышно по поводу поддержки 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, все должно работать.
Сценарий второй: я что-то там накодил, а потом решил все затереть, дабы никто из напарников не увидел мой быдлокод. Стераю код и отправляю Сохранить. Опять-таки получаю Успех и закрываю браузер. А потом тот же Сергей Прохоров обнаруживаем мой не затертый файл и начинает тыкать в меня пальцем.
И еще момент: вот отсутствие кода в запросе не всегда следует расценивать как ошибку (может я хочу стереть все в файл). Возвращать ошибочный ответ здесь нельзя. При этом и не записывать в файл здесь нельзя.
А вот отсутствие названия файла — конкретная ошибка, и в данном случае следует возвращать сообщение об ошибке.
А ограничивать только текущей директорией, это, во-первых, не добавляет безопасности, во-вторых, ограничивает функционал (может я хочу поредактировать статический сниппет какого-нибудь стороннего модуля).
Переносит документы, шаблоны и ТВ-шки. Чанки и сниппеты уже вручную переносятся (потому что все равно на Рево все это переписывать придется).
P.S. Просто код воспринимается проще, чем обычный текст))) Хотя и указано в комментарии «с указанием кодировки».
Второй большой недостаток, хотя и не такой важный: не использование источников файлов. Там не только работа с нужными директориями, но и сразу проверка прав на них. понятно дело, что в большинстве случаев консоль используют только разрабы самих сайтов, но все же.
В свое время я заморочился допиливанием механизма политик 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
Материал крайне мозговыносящий, но самый сок. Так что если освоите, понимать будете очень многое.
И получается, что он уже выше со своим комментарием.
Вряд ли что-то будет. Мы как-то с Джейсоном Ковардом разговаривали, и он выразил свое мнение, что innoDB переоценены, и что он не видит в них особого смысла. Есть там еще один момент важный, о котором я сейчас напишу в отдельной статье. Этот момент очень сильно мешает использованию innoDB, но у нас с Сергеем Прохоровым уже есть ответ на это счет, который вполне возможно будет отправлен в ядро, если Джейсон примет.
Как правильно выше написал Михаил — надо просто переключить таблицы в innoDB, и транзакции заработают.
Вызов этих функций именно то и дает, что выполняет SQL-запросы в текущей сессии на старт транзакций и т.п., ибо как и с другими запросами на это требуется авторизация на MySQL-сервере, обращение к БД и т.п. За это xPDO (в качестве PDO-обертки и отвечает, ибо подсасывает указанные в конфиги настройки соединения и т.п.).
Где я там говорил, что xPDO не умеет работать с innoDB??? Я сказал, что есть один локальный баг. Но метод xPDO::getIterator() мало где используется, так что вы вполне можете сделать свои innoDB-таблицы и просто не вызывать в работе с ними этот метод. В остальном все работает.
И еще раз: описанное Сергеем — это не домыслы, а длительная и конкретная практика на крупном и очень сложном проекте. И я тоже использовал транзакции на отдельных проектах, ибо иногда без них просто никуда.
Обновите этот класс и все. Других ошибок я не обнаружил. Так же при наличии файла core/model/modx/processors/element/propertyset/update.class.php (если вы обновлялись, а не устанавливали с нуля, должен присутствовать), можно просто удалить файл core/model/modx/processors/element/propertyset/updatefromelement.class.php, все должно работать.