Рубрика "Так лучше не делать"

В былые времена я принимал код MODX за образец и старался перенимать используемые в нём подходы и приёмы. И вот такой код

$this->fileHandler->modx->getCacheManager();

казался проявлением гибкости.

Но стоило только выглянуть за пределы MODX, в мир современной разработки, как оказалось, что такой подход считается вери бэд. Потому как понятный, хорошо поддерживаемый и легко тестируемый код должен следовать шаблону "Низкая связанность" (Low Coupling), описанный в законе Деметры. Т.е. объект не должен иметь зависимость от третьих объектов. Сегодня это обязательное требование в разработке.

https://habr.com/ru/post/319652/

Смотришь на этот код и думаешь, ошибок вроде нет, но какой смысл в этой проверке, непонятно.

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

https://modzone.ru/blog/2021/08/01/disabling-sessions-for-bots/

В шаблонизаторе Fenom библиотеки pdoTools есть объект $_modx, заменяющий реальный объект $modx. Сделано это, со слов автора, для безопасности, чтобы злой контент-менеджер не нахулиганил безобразия. Лично мне данная проблема кажется немного надуманной. Потому как, если вы пустили пользователя в админку, то безопасность сайта уже под угрозой. А с установленным pdoTools контент-менеджер может легко превратиться в админа сайта.

Ну а про $_modx можно сказать, что он нужен если только для удобства (хотя это тоже спорный вопрос). Ведь опытный разработчик легко узнает из документации Fenom, что есть такая системная переменная $.globals, которая является ссылкой на массив $GLOBALS, содержащий объект $modx.

В общем, вооружен, значит предупреждён. Или наоборот ;)

https://github.com/fenom-template/fenom/blob/master/docs/ru/syntax.md#%D0%9F%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5

Как и обещал, выпустил статью, в которой разобрал известные мне уязвимости, которые автор pdoTools посчитал неопасными. Лично я считаю их критическими, поэтому предлагаю варианты их устранения.

П.С. По сами знаете каким соображениям доступ к статье для гостей и поисковиков ограничен.

https://modzone.ru/blog/2021/08/06/closing-vulnerabilities-of-pdotools/

В продолжении темы про безопасность...
Любой контент-менеджер может получить значение любой системной настройки - [[++mail_smtp_pass]]. Например, логины и пароли к различным сервисам. Поэтому нужно понимать, что если уж вы дали доступ к сайту человеку, то вы должны быть в нём максимально уверены. Так как всё зависит от его порядочности.

Наглядная демонстрация как с помощью функционала файловых элементов pdoTools можно легко вывести содержимое любого файла на странице.

Вышел PhpStorm 2021.2

В этом релизе сильно продвинулись с поддержкой дженериков и начали выкатывать поддержку PHP 8.1. Также исправили все проблемы с форматированием и улучшили рефакторинг Extract method.

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

https://habr.com/ru/company/JetBrains/blog/571962/

У меня большие планы на ZoomX и его более крутой вариант с применением фреймворка Slim и контейнера зависимостей PHP-DI. Очень хочется, чтобы хотя бы в режиме фреймворка MODX был ближе к современным стандартам. Конечно дотянуть ядро до PSR - задача нереальная. Но добавить полноценную шаблонизацию (уже сделано) и автозагрузку классов вместо include и require, вполне по силам. А в старшей версии появится и внедрение зависимостей и middleware.

В ZoomX уже реализован RESTful API, завязанный на логику MODX. Вариант со Slim будет работать уже по фреймворковским правилам - с соблюдением PSR и внедрением зависимостей в роутах.

Друзья, а вы понимаете всю конструкцию с замороженным проектом pdoTools? Автор отказался его передавать кому-либо из-за его огромной важности. pdoTools является главной зависимостью таких компонентов как miniShop2, Tickets и ряд других. Многие также используют его в своих компонентах. Но теперь этот проект поддерживаться не будет, а автор предлагает делать форки. Как вы понимаете, такой важный проект бросать нельзя. Даже если его не развивать, то закрывать баги и дырки необходимо. Я вижу одно решение - создавать форк и указывать его в качестве зависимости как минимум в таких проектах как miniShop2 и Tickets. А вы что думаете?

Предыдущий пост не просто так написан. У меня есть более подробная статья про то как вызывать любые файлы на странице (см. пост от 8 августа). Несмотря на то, что закрытые статьи читают единицы, я всё-таки решил её не публиковать до того момента, пока мы не определимся с судьбой pdoTools. Но думаю, сообразительных и без меня хватает.

В сети можно найти сайты, у которых открыто ядро /core/, которые не фильтруют входные данные, у которых неправильные права на папки и т.п. Поэтому взлом таких сайтов - вопрос времени. Это как с phpThumb. Женя Борисов сколько говорил про дыру. В итоге 3 года назад массовый взлом.

Кстати, 3 года назад благодаря Жене я нашёл огромную дыру в mSearch2, но тогда Василий быстро отреагировал. Иначе мы бы получили массовый взлом сайтов с mSearch2 и соседних по VPS. С pdoTools ситуация обратная. А теперь вообще всё подвисло в воздухе.

Ещё одна небольшая статья в продолжение предыдущей про безопасность pdoTools. В ней есть вопросы для размышления, о которых нужно как минимум знать.

https://modzone.ru/blog/2021/08/16/about-pdotools-again/

Интересная технология -
https://github.com/chrome-php/chrome/

Пояснение данной технологии
https://habr.com/ru/company/oleg-bunin/blog/421137/

Продолжаю толкать MODX в сторону фреймворков. Добавил в ZoomX автозагрузку базовых классов MODX и даже классов из процессоров. Теперь при расширении базового класса не нужно инклюдить исходный класс. Т.е. сейчас это выглядит так

<?php 

include MODX_CORE_PATH . 'model/modx/modrequest.class.php'; 

class myRequest extends modRequest {...}

После установки ZoomX include уже не нужен.

Конечно, не PSR-4, но так гораздо удобнее.

Неожиданное наблюдение. Встречаю уже не первый большой проект, в котором игнорируют журнал ошибок MODX. Такой подход немного удивляет. У больших сайтов/проектов повышенные требования ко всему - скорости, безопасности, бесперебойности, безошибочности функционала, UI/UX, и т.п.

А вы считаете контроль за журналом ошибок важным элементом администрирования сайта?

Не про программирование.
Вчера с семьёй ездили на форум "Армия 2021" в парке Патриот. Посмотрели на современную военную технику, дети полазили, пофоткались. Потом решили поехать на динамический показ военной техники в Алабино (так где проходит танковый биатлон).

Это, конечно, я вам скажу, непередаваемые впечатления. Дети даже удивлялись как можно воевать на войне, если даже на трибуне от выстрела танка и запуска Града закладывает уши и всё вокруг трясётся. Надеюсь, они этого не узнают. Но общее впечатление получили. Мы в детстве о таком шоу могли только мечтать.

https://www.youtube.com/watch?v=u0Q_uvyfSdo

Рубрика "Так лучше не делать"

Велосипед от разработчика, который не знал про функцию trim -

if ($propValue[0] == '`' && $propValue[strlen($propValue) - 1] == '`') {
    $propValue= substr($propValue, 1, strlen($propValue) - 2);
}

Н - находчивость.

Для MODX намечается серьезная проблема.

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

https://modx.pro/components/22218

Я вот думаю записать видос с наглядной демонстрацией уязвимостей pdoTools, которые были закрыты в последней версии. Интересно было бы или можно не тратить время?