Comments 32
Я тоже писал велосипед и он работал лет 6. Потом встали сложные задачи, и продолжать писать свои обработчики форм, csrf, rest и дальше, я уже не хотел. Я перешел на фреймворк, и очень хорошо сделал. Во-первых это дало безопасность, а во-вторых концентрацию на глобальных бизнес задачах
Для сайта визитки или просто каталога товаров использовать Yii2, а тем более Symphony это имхо перебор.
А если без админки, то откуда статьи и каталоги?
Сори, не правильно понял
CSRF атака не подразумевает знание пароля. В общем то, если знаешь пароль, то атака (как и защита от неё) уже не нужна. Посмотрите на Википедии описание этой атаки, она очень простая.
> В общем то, если знаешь пароль, то атака (как и защита от неё) уже не нужна.
Если пользователь авторизован чтобы заходить в админский раздел то дальше у него полный карт бланш. Хотя нифига не полный: подготовленные SQL запросы. Я использую mysqli а не PDO, но даже через mysqli их можно делать кто бы чего не говорил :)
Но да, если он зарегистрирован то дальше CSRF атаку можно провести. Спасибо, добавлю проверки.
Немного проясню, если не используется флаг same-site в печеньках и токен, то просто Вы переходите по ссылке, где есть вредоносный код, выполняющий в Вашей админке какие-то действия от лица админа, то они выполнятся, если разрешит браузер (сейчас давно идёт тенденция разграничения печенек в браузере) и как бы Вы не закрывали админку (фаерволом, ключами и т.п.) это не будет иметь никакой разницы, потому что запрос выпросит именно Ваш браузер, с который имеет сессионную печеньку и который имеет доступ к админке. Предвидя вопрос, а как хацкеры угадают что нужно сделать в админке - отвечу, это уже безопасность через неопределённость, то не есть безопасностью.
Единственное, что пол-жизни слишком долго… Если бы хотя бы 3-5 лет…
Хотелось бы больше фактуры. сейчас статья выглядит, как мемасик:
Говнокод
Говнокод
???
PROFIT!!!
То, что CSRF не используется в админке говорит о том, что там ещё говноархитектура и/или говнорешения
Кода в статье нет.
Вообще, очень полезно прочитывать свою статью перед публикацией.
В частности, на предмет соответствия текста заявленной цели.
Я сейчас кратко изложу содержание
- Начало — говнокод на инклюдах
- Продолжение — попробовал битрикс (сам по себе говнокод), немножечко писал на Йии (тоже не лучший пример), своя поделка — все тот же говнокод
- Прозрение — половина раздела посвящена переименованию папочки. Из "правильной архитектуры" упомянуто три слова, Twig и CRUD и тесты. При том что crud — понятие растяжимое, а покрытие тестами, как я понимаю, процентов 5. при том что внедрение тестов на говнокод действительно могло бы быть интересным кейсом для рассказать.
- Решение — освоил композер и стал использовать пару готовых модулей.
В сухом остатке, если отбросить многословные экскурсы про сисадминскую вольницу, остается Твиг и композер. На статью никак не тянет.
Единственное, что можно действительно вынести из статьи — это неумение учиться на собственных ошибках. Потому что после
появление ООП в PHP, хотя последнее я просто не воспринял: зачем, когда у тебя в inc/
прямо бросается в глаза утверждение-близнец:
например DI контейнер в такой простой задаче будет перебором
С одной стороны я согласен, что сам по себе контейнер, как самоцель, будет скорее антипаттерном. Но вот нормальная архитектура, построенная на автоматическом создании объектов-сервисов и пробрасывания их в конечные объекты-потребители с помощью контейнера, как раз и решила бы проблему "связности в моей ЦМС", которая в итоге перестала бы напоминать Йии1-2 с его фреймворком, который весь лежит в одном объекте.
Но вот нормальная архитектура, построенная на автоматическом создании объектов-сервисов и пробрасывания их в конечные объекты-потребители с помощью контейнера, как раз и решила бы проблему «связности в моей ЦМС», которая в итоге перестала бы напоминать Йии1-2 с его фреймворком, который весь лежит в одном объекте.
Спасибо! Я и сам это понимаю, супер объект это уж точно антипаттерн :( Но он удобен :((( Но надо перестать его использовать.
Глянул код. Почитайте ещё за SOLID
Код может и вырос в ваших глазах, но он на уровне 2010 года сейчас примерно
Так посыл стати что всегда надо двигаться дальше!
Но в 2010 я не мог писать так:
public function actionActive(int $part_id, int $id, string $active): string
{
$model = new CatalogItem($id);
$model->active = $active;
$model->save();
echo $active;
exit;
}
А уже пишу.
Да, надо было в статье это показать. Видимо в следующей статье это сделаю.
А скажите, как я могу следовать SOLID и при этом чтобы небыло оверинжинирнга? Я в статье не уверен что для такой простой задачи нужен контейнер. Ну реально: просто получаю реквест и по роутингу отдтаю контроллеру который даёт респонс.
Да, тестировать такое сложно, спасибо что мне сказали это.
Да, по SOLID, мне интерфейсов сделать/задействовать примерно чуть больше чем ноль. В чём плюс кроме как что мои модули смогу использоваться в других проектах?
Это хорошо, я рад помочь другим людям.
Ну мы уходим от темы моей статьи: работает, быстро работает. Хотя использование Twig это уже абстракция над абстракцией, благо кешируется.
Всем вопросам вопрос.
Как сказал один очень умный человек, "то что одному — логичная и последовательная структура, то другому — оверинжиниринг". Все зависит от опыта.
Здесь я рекомендую смотреть на Симфони, как на проект, который пытается форсить правильные подходы, не заигрывая при этом с пользователем, как веселая Лариска, но при этом сохраняя мозг пользователя почти без необратимых повреждений.
Как сказал один очень умный человек, «то что одному — логичная и последовательная структура, то другому — оверинжиниринг». Все зависит от опыта.А от задачи разве не зависит?
но при этом сохраняя мозг пользователя почти без необратимых поврежденийСпасибо, после Yii2 вроде в порядке :)
Здесь я рекомендую смотреть на Симфони, как на проект, который пытается форсить правильные подходы
Так я уже использую консоль и Twig. Но надо свой код писать что понять красоту или перебор Симфони. Мой шаблонизатор укладывался в две функции. Сам PHP это шаблонизатор, но речь о другом. Не слишком ли много абстракций? Вопрос риторический.
В любом случае спасибо за рекомендацию!
а вот модуль админки и каталог товаров имеют ценность для ваших пользователейВы абсолютно правы!
Отсюда напрашивается направление дальнейшего развития: реализовать админку и каталог в виде PSR-4 модулей
не забыв абстрагироваться от слоя доступа к данным (паттерн репозиторий) Это позволит использовать ваши модули с любым популярным фрэймворком.Конечно! Это в планах! Почему я и хочу под PSR переписать!
. Сделать это в архитектуре REST (позволит четко отделить уровень презентации).Я уже заложил это: базовый контроллер выдаёт в JSON результат если там в result тип array :)
В довершение всего сделать фронтэнд SPA это позволит сделать функционально богатый и отзывчивый интерфейс.И стать фуллстэк? Я уже писал на Vue, но нет у меня пока ни времени, ни желания изучать TypeScript :)
SPA — это по желанию. Vue не требует знания TypeScript. Vue очень прост на самом деле…
Я знаю, пока просто думаю как мне его применить в свой проект. Но если уж тащить такую зависимость то используя TypeScript, чего мелочиться :)
Самая большая сложность, возможно, это настроить сборщик (Webpack сложен для меня...) я использую laravel-mix.com
Вы не поверите, я тоже! :) В зависимостях в package.json он и есть. Но в своём движке я в итоге сделал функцию
function get_webpack_asset(string $name) : string {
$file_name = App::$DIR . 'theme/mix-manifest.json';
if(!file_exists($file_name)) {
App::error('File mix-manifest.json not exists !');
return '';
}
$json = file_get_contents(App::$DIR . 'theme/mix-manifest.json');
$assets = my_json_decode($json);
if(!array_key_exists($name, $assets)) {
App::error('Key "' . $name . '" not exists in "mix-manifest.json"');
return '';
} else {
return $assets[$name];
}
}
чтобы не тащить ещё одну зависимость, stormiix/laravel-mix-twig-extension, в которой по сути делается тоже самое.
Я попробовал использовать symfony/webpack-encore-bundle, штука прикольная, кастомизации куда больше чем в laravel-mix, но я так и не смог настроить как мне надо. Может времени мало потратил (часа три), может у меня запросы специфичные. Но вернулся на laravel-mix. Вот мой конфиг:
let mix = require('laravel-mix');
mix
.setPublicPath('theme/')
.setResourceRoot('../')
.js('theme/assets/js/main.js', 'js')
.sass('theme/assets/sass/main.scss', 'css')
.copyDirectory('theme/assets/images', 'theme/images')
// .copyDirectory('theme/assets/fonts', 'theme/fonts')
.options({
processCssUrls: true
})
.version();
if ( !mix.inProduction() ) {
mix
.webpackConfig({devtool: 'source-map'})
.sourceMaps();
}
Я бегло изучил код, его кол-во и т.д. и как по мне, проще было взять чистый фреймворк и перенести кодовую базу в него, нежели пытаться файлики из yii внедорять в свой проект, на это есть одна простая причина — твой код необновляем. Вот представь, завтра выходит обновление ядра Yii, твои действия?
В общем я увидел исключительно небольшой рефакторинг кода и все, кодовая база небольших размеров. Глядя на твою CMS я не совсем понимаю в чем посыл твой? В том что ты написал код 2010 года и закинул туда пару файликов из Yii? Ну код ревью такой код не прошел бы.
P.s. В свое время я также занимался велосипедостроением (CMS разрабатывал). Начинал я это делать на фреймворке Kohana (Github) и он мне казался время мега крутым, но через год, он устарел и перестал развиваться и я принял решение переехать на новый фреймворк Laravel, который мне казался очень перспективным, тем самым.Куча модулей, сложный UI, я не представлял как перенести код с одного фреймворка на другой. Но я сделал это практически в одиночку (Github и Base Github), пришлось переделывать всё. Короче CMS умерла потому что я плохой маркетолог, хотя старался сделать ее на современных технологиях, оказывал поддержку, но не хватило сил сделать это в одиночку и привлечь для ее развития разработчиков, просто никому это не интересно. В России слишком маленька ЦА. Но главное, что я получил от использования фреймворков и интеграции с ними — это опыт работы с ними, изучение применяемых практик, ООП, паттерны проектирования и т.д.
Глядя на твою CMS я не совсем понимаю в чем посыл твой
Самобытная. Самописная. Она именно моя. Мой опыт. Об этом статья.
Кодовая база маленькая, но как код написан никто не обругал :) Я про стиль. Я так думаю для джуниора неплохо.
Да, я хотел критики. Я её получил.
Вот представь, завтра выходит обновление ядра Yii, твои действия?
Вот вообще не огорчусь: я взял у них идею а именно из файлов взял только Session.php.
Это такая фишка везде видеть Денисов Поповых?
[03:29:23 root@hosting:/home/htdocs/boot.nsk.ru]# grep -r Yii ./
./vendor/twig/twig/doc/intro.rst:Slim, Yii, Laravel, and Codeigniter — just to name a few.
./include/classes/Session.php: * Session is a Web application component that can be accessed via `Yii::$app->session`.
./include/classes/Session.php: * Starting with Yii 2.0.21 `sameSite` is also supported. It requires PHP version 7.3.0 or higher.
./include/classes/Session.php: * foreach (Yii::$app->session->getAllFlashes() as $key => $message) {
./include/classes/App.php: * @var Session Session implementation from Yii2 framework
Ну код ревью такой код не прошел бы.
Из-за одного файла?
Посыл статьи был как код шёл от плохого к хорошему. И скрытая просьба чтобы мне указали на ошибки. А в итоге сеньёры цепляются к одному файлу.
Проблема не в одном файле, а во всей системе. В современном мире важна скорость и качество разрабатываемого кода и сейчас ценятся те, кто умеет пользоваться инструментами. Уже давно существует такое кол-во фреймворков, которые проверены годами и их создатели, а также контрибьюторы потратили тысячи часов, чтобы сделать их удобными, избавить от дыр и создать вокруг них целую экосистему. Когда я собеседую людей, мне важно, чтобы разработчик знал патерны, мыслил тестами, умел работать с существующими инструментами.
Что касается твоего кода, то первый вопрос, зачем копировать к себе в «велосипед» куски чужого кода, если за это время можно было взять готовый фреймворк/микрофреймворк и на нем уже создать полноценный продукт? И тратить время на более важные вещи, а именно на свой рост.
Правильно ли я понимаю, что папка classes в CMS это скопированные классы из yii? Почему не затащил свой проект на базу Yii?
Только адаптировал classes\Session, и я там оставил копирайты. Видимо это было ошибкой.
Я бегло изучил код, его кол-во и т.д. и как по мне, проще было взять чистый фреймворк и перенести кодовую базу в него, нежели пытаться файлики из yii внедорять в свой проект, на это есть одна простая причина — твой код необновляем. Вот представь, завтра выходит обновление ядра Yii, твои действия?
А Вы точно видели код? Да, я вдохновлялся их кодом, но я вообще не использую их контейнер к примеру. Ну или как я с базой работаю, это же ActveRecord паттерн, я его скопировал?
Ну код ревью такой код не прошел бы.
С вашими требованиями не прошёл, спору нет.
Велосипед длиной в полжизни