Pull to refresh

Comments 32

Я тоже писал велосипед и он работал лет 6. Потом встали сложные задачи, и продолжать писать свои обработчики форм, csrf, rest и дальше, я уже не хотел. Я перешел на фреймворк, и очень хорошо сделал. Во-первых это дало безопасность, а во-вторых концентрацию на глобальных бизнес задачах

Так под серъёзные задачи бизнеса я сейчас пишу на Yii2, но и csrf у меня вполне поддерживается. Только для админского раздела я его вообще не применяю: если есть админский пароль то уже безопасность уже нифига не безопасность.
Для сайта визитки или просто каталога товаров использовать Yii2, а тем более Symphony это имхо перебор.

А если без админки, то откуда статьи и каталоги?

Разумеется есть админка, но если пользователь авторизован то у него есть в неё доступ. А раз авторизован то нафига CSRF проверки? Я считаю их лишними. К тому же сайты по https. Да, принудительно https, несмотря на недавние статьи.

CSRF атака не подразумевает знание пароля. В общем то, если знаешь пароль, то атака (как и защита от неё) уже не нужна. Посмотрите на Википедии описание этой атаки, она очень простая.

Так Вы сами ответили на свой вопрос:

> В общем то, если знаешь пароль, то атака (как и защита от неё) уже не нужна.

Если пользователь авторизован чтобы заходить в админский раздел то дальше у него полный карт бланш. Хотя нифига не полный: подготовленные SQL запросы. Я использую mysqli а не PDO, но даже через mysqli их можно делать кто бы чего не говорил :)
Но да, если он зарегистрирован то дальше CSRF атаку можно провести. Спасибо, добавлю проверки.

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

Написать что-то как можешь, потом изучить ООП, хорошие современные фреймворки, и переписать, но уже понимая почему это так, и почему не стоит иначе — это лучший тру путь.

Единственное, что пол-жизни слишком долго… Если бы хотя бы 3-5 лет…
Так главная работа была Linux админ. А когда админишь сервера и они годами работают то начинаешь стагнировать :(((( Деньги капают а ты ничего особо не делаешь. Ну только винчестеры в рейде менять и назад зеркало синхронизировать. 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 и при этом чтобы небыло оверинжинирнга? Я в статье не уверен что для такой простой задачи нужен контейнер. Ну реально: просто получаю реквест и по роутингу отдтаю контроллеру который даёт респонс.
Да, тестировать такое сложно, спасибо что мне сказали это.
Да, по SOLID, мне интерфейсов сделать/задействовать примерно чуть больше чем ноль. В чём плюс кроме как что мои модули смогу использоваться в других проектах?
Это хорошо, я рад помочь другим людям.
Ну мы уходим от темы моей статьи: работает, быстро работает. Хотя использование Twig это уже абстракция над абстракцией, благо кешируется.
> А скажите, как я могу следовать SOLID и при этом чтобы небыло оверинжинирнга?

Всем вопросам вопрос.

Как сказал один очень умный человек, "то что одному — логичная и последовательная структура, то другому — оверинжиниринг". Все зависит от опыта.


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

Как сказал один очень умный человек, «то что одному — логичная и последовательная структура, то другому — оверинжиниринг». Все зависит от опыта.
А от задачи разве не зависит?
но при этом сохраняя мозг пользователя почти без необратимых повреждений
Спасибо, после Yii2 вроде в порядке :)
Здесь я рекомендую смотреть на Симфони, как на проект, который пытается форсить правильные подходы

Так я уже использую консоль и Twig. Но надо свой код писать что понять красоту или перебор Симфони. Мой шаблонизатор укладывался в две функции. Сам PHP это шаблонизатор, но речь о другом. Не слишком ли много абстракций? Вопрос риторический.

В любом случае спасибо за рекомендацию!
Насколько я понял сам движок практической ценности не представляет а вот модуль админки и каталог товаров имеют ценность для ваших пользователей. Отсюда напрашивается направление дальнейшего развития: реализовать админку и каталог в виде PSR-4 модулей, не забыв абстрагироваться от слоя доступа к данным (паттерн репозиторий) Это позволит использовать ваши модули с любым популярным фрэймворком. Сделать это в архитектуре REST (позволит четко отделить уровень презентации). В довершение всего сделать фронтэнд SPA это позволит сделать функционально богатый и отзывчивый интерфейс.
а вот модуль админки и каталог товаров имеют ценность для ваших пользователей
Вы абсолютно правы!
Отсюда напрашивается направление дальнейшего развития: реализовать админку и каталог в виде PSR-4 модулей
не забыв абстрагироваться от слоя доступа к данным (паттерн репозиторий) Это позволит использовать ваши модули с любым популярным фрэймворком.
Конечно! Это в планах! Почему я и хочу под PSR переписать!
. Сделать это в архитектуре REST (позволит четко отделить уровень презентации).
Я уже заложил это: базовый контроллер выдаёт в JSON результат если там в result тип array :)
В довершение всего сделать фронтэнд SPA это позволит сделать функционально богатый и отзывчивый интерфейс.
И стать фуллстэк? Я уже писал на Vue, но нет у меня пока ни времени, ни желания изучать TypeScript :)
SPA — это по желанию. Vue не требует знания TypeScript. Vue очень прост на самом деле… Самая большая сложность, возможно, это настроить сборщик (Webpack сложен для меня...) я использую laravel-mix.com
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();
}
Правильно ли я понимаю, что папка classes в CMS это скопированные классы из yii? Почему не затащил свой проект на базу Yii?

Я бегло изучил код, его кол-во и т.д. и как по мне, проще было взять чистый фреймворк и перенести кодовую базу в него, нежели пытаться файлики из 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 паттерн, я его скопировал?

Ну код ревью такой код не прошел бы.


С вашими требованиями не прошёл, спору нет.
Sign up to leave a comment.

Articles