company_banner

Современный PHP без фреймворков

https://kevinsmith.io/modern-php-without-a-framework
  • Перевод
  • Tutorial


У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка. Я не собираюсь перечислять недостатки фреймворков, и это не проявление синдрома неприятия чужой разработки: в этом руководстве мы будем использовать пакеты, написанные разработчиками нескольких фреймворков. Я всецело уважаю инновации в этой сфере.


Но эта статья не о них. Она о вас. О возможности стать лучше как разработчик.


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


Возможно, ваша следующая работа не позволит вам насладиться запуском нового проекта без фреймворка. Многие важные, критические для бизнеса PHP-задачи подразумевают использование уже существующих приложений. И неважно, будет это приложение, построенное на современном фреймворке вроде Laravel или Symfony, на одной из старых платформ вроде CodeIgniter или FuelPHP — либо это удручающе широко распространённое легаси PHP-приложение с «include-oriented архитектурой»: если сейчас вы будете разрабатывать без фреймворка, то окажетесь лучше подготовлены к любому будущему PHP-проекту.


Раньше создавать без фреймворков пытались потому, что некоторые системы вынуждены интерпретировать и маршрутизировать HTTP-запросы, слать HTTP-ответы и управлять зависимостями. Нехватка стандартов неизбежно приводила к тому, что как минимум эти компоненты фреймворков были тесно взаимосвязаны. Так что если вы начинали разрабатывать проект без фреймворка, то в конце концов приходили к созданию своего собственного фреймворка.


Но сегодня благодаря стараниям PHP-FIG в сфере автозагрузки и взаимной совместимости вы можете разрабатывать без фреймворка, не создавая его попутно. Существует множество замечательных, взаимно совместимых пакетов, написанных многочисленными разработчиками. И собрать их в единую систему гораздо проще, чем вы думаете!


Как работает PHP?


Прежде всего важно понять, как PHP-приложения взаимодействуют с внешним миром.


PHP исполняет серверные приложения в цикле запрос/ответ. Всё взаимодействие с приложением — из браузера, командной строки или REST API — приходит в него в качестве запросов. При получении запроса приложение загружается, обрабатывает запрос и генерирует ответ, который передаётся обратно клиенту, а приложение закрывается. И так происходит при каждом обращении.


Контроллер запросов


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


Давайте воспользуемся классическим примером с Hello, world!, обслуживаемым встроенным в PHP веб-сервером, чтобы проверить, всё ли настроено корректно. Если вы этого ещё не сделали, то удостоверьтесь, что в среде установлен PHP 7.1 или выше.


Создадим директорию проекта, в ней сделаем вложенную директорию public, а внутри неё — файл index.php с таким кодом:


<?php
declare(strict_types=1);

echo 'Hello, world!';

Обратите внимание, здесь мы объявляем строгую типизацию — это нужно делать в начале каждого PHP-файла вашего приложения, — потому что подсказки типов (type hinting) важны для отладки и ясного понимания теми, кто будет заниматься кодом после вас.


Далее с помощью инструмента командной строки (вроде Terminal на MacOS) перейдём в директорию проекта и запустим встроенный в PHP веб-сервер.


php -S localhost:8080 -t public/

Теперь откроем в браузере адрес http://localhost:8080/. Отображается Hello, world! без ошибок?


Отлично. Переходим к следующему шагу!


Автозагрузка и сторонние пакеты


Когда вы впервые начали работать с PHP, то, вероятно, использовали выражения include или require для получения функциональности или конфигураций из других PHP-файлов. В целом этого лучше избегать, потому что другим людям потом будет гораздо труднее разобраться в коде и понять, где находятся зависимости. Это превращает отладку в кошмар.


Выход — автозагрузка. Это означает, что, когда вашему приложению нужно использовать какой-то класс, PHP знает, где его найти, и автоматически загружает в момент вызова. Эта возможность существует со времён PHP 5, но стала активно применяться только с появлением PSR-0 (стандарта автозагрузки, сегодня заменён PSR-4).


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


Проверьте, что у вас установлен Composer. Затем настройте его для своего проекта.


composer init

После этого пройдите через интерактивное руководство по генерированию конфигурационного файла composer.json. Затем откройте его в редакторе и добавьте поле autoload, чтобы получилось так, как показано ниже (тогда автозагрузчик будет знать, где искать ваши классы).


{
    "name": "kevinsmith/no-framework",
    "description": "An example of a modern PHP application bootstrapped without a framework.",
    "type": "project",
    "require": {},
    "autoload": {
        "psr-4": {
            "ExampleApp\\": "src/"
        }
    }
}

Теперь установите для этого проекта Composer, которые подтянет все зависимости (если они уже есть) и настроит для нас автозагрузчик.


composer install

Обновите public/index.php для запуска автозагрузчика. В идеале это одно из нескольких выражений include, которые вы используете в приложении.


<?php
declare(strict_types=1);

require_once dirname(__DIR__) . '/vendor/autoload.php';

echo 'Hello, world!';

Если перезагрузить приложение в браузере, вы не увидите никакой разницы. Однако автозагрузчик работает, просто он не делает ничего тяжёлого. Давайте перенесём пример с Hello, world! в автоматически загружаемый класс, чтобы проверить, как всё работает.


В корне проекта создадим папку src и вставим в неё файл HelloWorld.php с таким кодом:


<?php
declare(strict_types=1);

namespace ExampleApp;

class HelloWorld
{
    public function announce(): void
    {
        echo 'Hello, autoloaded world!';
    }
}

Теперь в public/index.php замените выражение echo вызовом метода announce в классе HelloWorld.


// ...

require_once dirname(__DIR__) . '/vendor/autoload.php';

$helloWorld = new \ExampleApp\HelloWorld();
$helloWorld->announce();

Перезагрузите приложение в браузере и увидите новое сообщение!


Что такое внедрение зависимостей?


Внедрение зависимостей — это методика, при которой каждая зависимость предоставляется объекту, которому она требуется, вместо того чтобы объект обращался наружу за получением какой-то информации или функциональности.


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


class AwesomeClass
{
    public function doSomethingAwesome()
    {
        $dbConnection = return new \PDO(
            "{$_ENV['type']}:host={$_ENV['host']};dbname={$_ENV['name']}",
            $_ENV['user'],
            $_ENV['pass']
        );

        // Make magic happen with $dbConnection
    }
}

Но это не лучшее решение. На чуждый метод возлагается ответственность за создание объекта нового подключения к БД, получения учётных данных и обработки любых проблем в случае сбоя подключения. В результате в приложении дублируется масса кода. А если вы попытаетесь прогнать этот класс через модульное тестирование, то не сможете. Класс тесно взаимосвязан со средой приложения и базой данных.


Давайте с самого начала не будем усложнять работу с тем, что требуется классу. Просто в первую очередь потребуем, чтобы объект PDO был внедрён в класс.


class AwesomeClass
{
    private $dbConnection;

    public function __construct(\PDO $dbConnection)
    {
        $this->dbConnection = $dbConnection;
    }

    public function doSomethingAwesome()
    {        
        // Make magic happen with $this->dbConnection
    }
}

Получилось гораздо чище и проще для понимания, меньше вероятность ошибок. Благодаря подсказке типов и внедрению зависимостей метод объявляет именно то, что ему нужно для выполнения задачи, и получает необходимое без вызова из себя внешней зависимости. А когда речь пойдёт о модульном тестировании, мы окажемся готовы к моделированию подключения к БД и спокойно пройдём тест.


Контейнер внедрения зависимости — это инструмент, в который вы обёртываете всё ваше приложение ради создания и внедрения этих самых зависимостей. Контейнер не является необходимым, но значительно облегчает жизнь по мере роста и усложнения вашего приложения.


Мы воспользуемся самым популярным DI-контейнером для PHP с изобретательным названием PHP-DI. (Надо отметить, что в его документации внедрение зависимостей описано иначе, и кому-то так будет понятнее.)


Контейнер внедрения зависимостей


Поскольку мы настроили Composer, установка PHP-DI пройдёт практически безболезненно. Для этого снова обратимся к командной строке:


composer require php-di/php-di

Обновите public/index.php для конфигурирования и сборки контейнера.


// ...

require_once dirname(__DIR__) . '/vendor/autoload.php';

$containerBuilder = new \DI\ContainerBuilder();
$containerBuilder->useAutowiring(false);
$containerBuilder->useAnnotations(false);
$containerBuilder->addDefinitions([
    \ExampleApp\HelloWorld::class => \DI\create(\ExampleApp\HelloWorld::class)
]);

$container = $containerBuilder->build();

$helloWorld = $container->get(\ExampleApp\HelloWorld::class);
$helloWorld->announce();

Ничего особенного пока не произошло. Это лишь простой пример, где всё необходимое помещено в один файл для удобства наблюдения.


Мы конфигурируем контейнер, поэтому нужно явно объявить зависимости (а не использовать автоматическое внедрение или аннотации) и извлечь из контейнера объект HelloWorld.


Заметка на полях: автоматическое внедрение зависимостей может быть полезной фичей в начале создания приложения, но в дальнейшем оно усложняет сопровождение, поскольку зависимости остаются относительно скрытыми. К тому же возможно, что через несколько лет другой разработчик подключит какую-нибудь библиотеку, и в результате несколько библиотек будут реализовывать один интерфейс. Это сломает автоматическое внедрение зависимостей и приведёт к непредсказуемому потоку багов. Разработчик, внёсший изменение, может их вообще не заметить.


Давайте ещё больше всё упростим, импортировав пространства имён там, где это возможно.


<?php
declare(strict_types=1);

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use function DI\create;

require_once dirname(__DIR__) . '/vendor/autoload.php';

$containerBuilder = new ContainerBuilder();
$containerBuilder->useAutowiring(false);
$containerBuilder->useAnnotations(false);
$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
]);

$container = $containerBuilder->build();

$helloWorld = $container->get(HelloWorld::class);
$helloWorld->announce();

Пока что выглядит всё так, словно мы устроили суматоху ради выполнения того, что уже делали раньше.


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


https://kevinsmith.io/modern-php-without-a-framework-middleware


Middleware


Если представить приложение в виде луковицы, в которой запросы идут снаружи к центру, а ответы в обратном направлении, то middleware — это каждый слой луковицы, который получает запросы, вероятно, что-то делает с ответами и передаёт их в нижний слой либо генерирует ответ и отправляет в верхний слой. Такое случается, если промежуточный слой проверяет запросы на соответствие каким-то условиям вроде запроса несуществующего пути.


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


Варианты использования промежуточных слоев:


  • Отладка проблем при разработке.
  • Постепенная обработка исключений в production.
  • Ограничение частоты входящих запросов.
  • Ответы на запросы неподдерживаемых медиатипов.
  • Обработка CORS.
  • Маршрутизация запросов в соответствующие обрабатывающие классы.

Промежуточный слой — это единственный способ реализации инструментов для обработки всех этих ситуаций? Вовсе нет. Но реализации middleware позволяют сделать цикл запрос/ответ гораздо понятнее, что сильно упростит отладку и ускорит разработку.


Мы воспользуемся промежуточным слоем для последнего сценария: маршрутизации.


Маршрутизация


Маршрутизатор применяет информацию из запроса, чтобы понять, какой класс должен его обработать (например, URI /products/purple-dress/medium должен быть обработан с помощью класса ProductDetails::class с передаваемыми в качестве аргументов purple-dress и medium).


Наше приложение будет использовать популярный маршрутизатор FastRoute через реализацию промежуточного слоя, совместимого с PSR-15.


Диспетчер middleware


Чтобы наше приложение стало работать с каким-либо промежуточным слоем, нам понадобится диспетчер.


PSR-15 — это стандарт, определяющий интерфейсы для middleware и диспетчеров (в спецификации они называются «обработчики запросов»), обеспечивающий взаимосовместимость широкого спектра решений. Нам лишь нужно выбрать диспетчер, совместимый с PSR-15, и он будет работать с любым совместимым middleware.


В качестве диспетчера установим Relay.


composer require relay/relay:2.x@dev

А поскольку спецификация PSR-15 подразумевает, чтобы реализация промежуточного слоя передавала HTTP-сообщения, совместимые с PSR-7, мы воспользуемся Zend Diactoros.


composer require zendframework/zend-diactoros

Подготовим Relay к приёму промежуточных слоев.


// ...

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use Relay\Relay;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$container = $containerBuilder->build();

$middlewareQueue = [];

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

В строке 16 мы с помощью ServerRequestFactory::fromGlobals() будем собирать всю информацию, необходимую для создания нового запроса и передачи его Relay. Здесь запрос попадает в стек промежуточных слоев.


Теперь добавим FastRoute и обработчика запросов (FastRoute определяет, валиден ли запрос и может ли он быть обработан нашим приложением, а обработчик запросов передаёт запрос тому обработчику, что сконфигурирован для этого маршрута).


composer require middlewares/fast-route middlewares/request-handler

А теперь определим маршрут для класса обработчика Hello, world!.. Здесь мы воспользуемся маршрутом /hello, чтобы продемонстрировать возможность использования маршрута, отличающегося от базового URI.


// ...

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use FastRoute\RouteCollector;
use Middlewares\FastRoute;
use Middlewares\RequestHandler;
use Relay\Relay;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;
use function FastRoute\simpleDispatcher;

// ...

$container = $containerBuilder->build();

$routes = simpleDispatcher(function (RouteCollector $r) {
    $r->get('/hello', HelloWorld::class);
});

$middlewareQueue[] = new FastRoute($routes);
$middlewareQueue[] = new RequestHandler();

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

Чтобы всё заработало, нужно обновить HelloWorld, сделав его вызываемым классом, то есть чтобы этот класс можно было вызвать как функцию.


// ...

class HelloWorld
{
    public function __invoke(): void
    {
        echo 'Hello, autoloaded world!';
        exit;
    }
}

Обратите внимание на добавленный exit; в магическом методе __invoke(). Скоро вы поймёте, к чему это.


Теперь откройте http://localhost:8080/hello и наслаждайтесь своим успехом!


Клей, который всё скрепляет вместе


Проницательный читатель заметит, что DI-контейнер, несмотря на все трудности его конфигурирования и сборки, на самом деле ничего не делает. Диспетчер и промежуточное ПО могут работать и без контейнера.


Так зачем он нужен?


А что, если — как это почти всегда бывает в реальных приложениях — у класса HelloWorld есть зависимость?


Давайте её добавим и посмотрим, что произойдёт.


// ...

class HelloWorld
{
    private $foo;

    public function __construct(string $foo)
    {
        $this->foo = $foo;
    }

    public function __invoke(): void
    {
        echo "Hello, {$this->foo} world!";
        exit;
    }
}

Перезагрузим браузер, и...


Ой.


Видим ArgumentCountError.


Это происходит потому, что для функционирования HelloWorld требуется при его создании внедрить строковое значение, а у нас это повисло в воздухе. И здесь на помощь приходит контейнер.


Давайте определим зависимость в контейнере и передадим его в RequestHandler для разрешения.


// ...

use Zend\Diactoros\ServerRequestFactory;
use function DI\create;
use function DI\get;
use function FastRoute\simpleDispatcher;

// ...

$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
        ->constructor(get('Foo')),
    'Foo' => 'bar'
]);

$container = $containerBuilder->build();

// ...

$middlewareQueue[] = new FastRoute($routes);
$middlewareQueue[] = new RequestHandler($container);

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

Вуаля! При перезагрузке браузера вы должны увидеть Hello, bar world!.


Правильная отправка ответов


Помните, я упомянул о выражении exit в HelloWorld?


Это простой способ удостовериться, что мы получили простой ответ, но всё же это не лучший способ отправки выходных данных в браузер. Такой грубый подход заставляет HelloWorld делать лишнюю работу по отдаче отчетов — а этим должен заниматься другой класс, — что слишком усложняет отправку заголовков и кодов статуса, а также приводит к закрытию приложения, не давая шансов запуститься промежуточному ПО, идущему после HelloWorld.


Помните, что каждый промежуточный слой имеет возможность модифицировать запрос по пути в приложение, а также (в обратном порядке) модифицировать ответ по пути из приложения. В дополнение к стандартному интерфейсу для Request PSR-7 определяет структуру ещё одного HTTP-сообщения, которое будет нам полезно на обратной ветке цикла: Response. Если хотите, можете почитать подробнее о HTTP-сообщениях и о том, чем хороши стандарты PSR-7 Request и Response.


Обновим HelloWorld для возвращения Response.


// ...

namespace ExampleApp;

use Psr\Http\Message\ResponseInterface;

class HelloWorld
{
    private $foo;

    private $response;

    public function __construct(
        string $foo,
        ResponseInterface $response
    ) {
        $this->foo = $foo;
        $this->response = $response;
    }

    public function __invoke(): ResponseInterface
    {
        $response = $this->response->withHeader('Content-Type', 'text/html');
        $response->getBody()
            ->write("<html><head></head><body>Hello, {$this->foo} world!</body></html>");

        return $response;
    }
}

Обновим определение контейнера, чтоб HelloWorld предоставлялся со свежим объектом Response.


// ...

use Middlewares\RequestHandler;
use Relay\Relay;
use Zend\Diactoros\Response;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
        ->constructor(get('Foo'), get('Response')),
    'Foo' => 'bar',
    'Response' => function() {
        return new Response();
    },
]);

$container = $containerBuilder->build();

// ...

Если мы сейчас обновим страницу, то получим пустой экран. Приложение возвращает из диспетчера промежуточных слоев правильный объект Response, а потом… что?


Просто ничего с ним не делает.


Нам нужен ещё один инструмент: эмиттер. Он находится между приложением и веб-сервером (Apache, nginx и т. д.) и отправляет ваш ответ клиенту, сгенерировавшему запрос. Эмиттер просто берёт объект Response и преобразует в инструкции, доступные для понимания серверным API.


Хорошие новости! Пакет Zend Diactoros, который мы уже используем для управления запросами, включает в себя эмиттер для ответов PSR-7.


Для простоты примера мы используем здесь очень простой эмиттер. Хотя он может быть гораздо сложнее, но в случае больших загрузок реальное приложение должно быть сконфигурировано для автоматического использования потокового эмиттера. Это хорошо описано в блоге Zend.


Обновим public/index.php для получения Response от диспетчера и передачи в эмиттер.


// ...

use Relay\Relay;
use Zend\Diactoros\Response;
use Zend\Diactoros\Response\SapiEmitter;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$requestHandler = new Relay($middlewareQueue);
$response = $requestHandler->handle(ServerRequestFactory::fromGlobals());

$emitter = new SapiEmitter();
return $emitter->emit($response);

Перезагрузим страницу — мы снова в деле! Пришло время для более надёжной обработки ответов.


В строке 15 заканчивается цикл запрос/ответ и вступает в работу веб-сервер.


Завершение


С помощью 44 строк кода и нескольких широко используемых, тщательно протестированных, надёжных, взаимодействующих друг с другом компонентов мы реализовали программу bootstrap современного PHP-приложения. Он совместим со стандартами PSR-4, PSR-7, PSR-11 и PSR-15, поэтому вам доступен широкий спектр реализаций HTTP-сообщений, DI-контейнеров, middleware и диспетчеров.


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


Использованное в статье приложение лежит в репозитории, можете свободно форкать и скачивать.


Если хотите почитать о качественных несвязанных пакетах, то очень рекомендую ознакомиться с Aura, The League of Extraordinary Packages, компонентами Symfony, компонентами Zend Framework, заточенными под безопасность библиотеками Paragon Initiative и списком совместимого с PSR-15 middlleware.


Если воспользуетесь этим кодом в production, то, вероятно, вам понадобится вынести маршруты и определения контейнера в отдельные файлы, чтобы легче было сопровождать их по мере усложнения проекта. Также рекомендую реализовать EmitterStack для «умной» обработки скачиваний файлов и прочих больших ответов.

Mail.Ru Group 643,47
Строим Интернет
Поделиться публикацией
Похожие публикации
Комментарии 264
  • +13
    У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка.

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


    обьясните мне пожалуйста почему первая цитата не исключает действия из второй? почему в первом случае нас агитируют заниматься тягомотиной, а во втором случае нет?
    • –2

      Потому что фреймворк это не загрузчик, наверное :)

      • +3
        Вот да.
        С одной стороны как человек который таки да, писал все с нуля, и действительно серьезно подтянул скилсы в чужих фрейворках — да, это как-то странновато использовать готовые пакеты пытаясь написать «с нуля». Тем более что внутрянку пакетов не затронули. С другой стороны… ну вот минимальный базовый функционал, так чтобы оно реально было применимо в продакшене — меньше 20килобайт кода не завесит. Плюс PSRы разобрать, объяснить. Тесты и т.п… В общем статей сорок уйдет на примерно тоже самое.
        А так хоть стандарты людям будут известны.
        Итого: Да, статья не очень соответствует заголовку и началу, но полезно. Местами.
        • +3
          Я честно говоря не понимаю, чем по сложности такой способ «без фреймворка» отличается от, собственно, разбора фреймворка.

          Работать на таком монстре будет сильно сложнее, понимания работы конкретных элементов он не добавил; в итоге получился просто фреймворк из компонентов других фреймворков (правда без нормальной работы с базой), полезность которого сомнительна
          • +2
            Без базы, без шаблонизатора, без MVC… много еще без чего.
            Вообще вы конечно правы, это я что-то затупил под вечер.
            У меня мой фреймворк занимает чуть больше мегабайта кода.
            Неоднократно порывался выложить в паблик, кратенько писать «историю создания» примерно в таком стиле и т.п.
            И тут на автопилоте ощущения от того масштаба работы взял, да и сравнил с вот этим вот куцым описанием процесса сборки из кусочков.
            Действительно, если так по верхам описывать как здесь, то будет ничуть не больше. Правда и ничуть не понятнее).
            • +1
              Идея интересная, но так как у подобных решений нет нормальной документации, будет крайне неудобно поддерживать проект на этом велосипеде (и пусть он использует много фишек типа PSR, DI и прочего).

              Вопрос работы с бд тоже довольно холиварная тема, поэтому ее и не описывал автор. Сложно будет доказать когда оправдан ActiveRecord, а когда DataMapper. И там тоже все на магии, если самому реализовывать.

              Данная статья удобна для стажеров. Буду давать ее для изучение перед изучение полноценных фреймворков.
        • +9
          Вместо того, чтобы использовать готовый и уже собранный [микро]фреймворк, автор собрали собственный микрофреймворк из готовых компонентов. Так что «без фреймворков» — ложь.

          В отличие от этого поверхностного «воткните штекер А в гнездо Б», у Дмитрия Елисеева идёт детальный разбор того, как каждый компонент работает и почему это устроено именно так.
          • 0
            Ну так задача была — напишем сами, и все сами поймем. В статье особо ничего и не написано — придется разбираться самим. Так что все правильно)
            • +1
              На мой взгляд, в статье посыл правильный, хотя и не очень удачно донесенный: набор компонентов должен отталкиваться от задач. Компоненты вполне могут быть из одного фреймворка, но нужно понимание того, для чего они используются. Конкретно в приведенном примере, чтобы вывести «Hello world» нам не нужна ORM, QueryBuilder и еще многое из того ливера, который почти в любом фреймворке будет у нас из коробки.
              • 0
                Я уже очень далек от PHP, но в свое время(когда только появился композер) меня дико напрягало:
                1. Разная философия пакетов (ларавель использующий колбек вызов свифт мейлера, когда мне нужно было на лету что-то модифицировать в отправке).
                2. Пакеты, не заточенные под композер, в которых настройки прошиты где-то в их папке и вынести нормально эти настройки не было возможности.
                Может быть сейчас все изменилось, но все-равно не думаю, что правильно собирать такого Франкенштейна, ведь плюс любого хорошего фреймворка в однотипном написании всех его компонентов.
                • 0
                  Какие проблемы — берите компоненты из одного фреймворка. Просто если вам нужен один-два компонента, зачем тащить фреймворк целиком?
                  • 0
                    А из каких фреймворков сейчас можно нормально брать компоненты чтобы писать с нуля, и, я реально отстал от жизни PHP(больше 4 лет не касался), какие компоненты каких фреймворков имеет смысл сочетать? Вот из этих habrahabr.ru/company/nixsolutions/blog/329718
                    • 0
                      Из Symfony, и, в принципе, наверное можно и из Zend. Тот же laravel более чем наполовину состоит из компонентов Symfony
                      • +1

                        двушка симфы изначально так и писалась, из зенда на уровне 1.х можно было брать либы. из ларавеля и из юи брать не имеет смысла из-за зависимостей и уникальности, я правильно понимаю? Тогда зачем изобретать надуманные кейсы? Как и в js и pythone есть независимые либы, которые независимо и подключаются(свифт), а плагины(пакеты) писались и пишутся под конкретный фреймворк. Я скажу про питон, что если мне нужно что-то простое, я возьму бутылку, и точно не буду к ней использовать джанго пакеты, так же как в реакте не буду пользовать ангулар пакеты.

                        • +1

                          В экосистеме Symfony есть три основных типа либ: бандлы, бриджи и компоненты. Компоненты — самодостаточные либы, не зависящие от фреймворка, которые можно брать и использовать практически в любом приложении. Бриджи обычно — низкоуровневые адаптеры над либами, прежде всего сторонними, приводящие их к Symfony-way API/UI и(или) обратно (родные компоненты Symfony по понятным причинам обычно в них не нуждаются). Бандлы — обычно тесно интегрированы с фреймворком, в том числе с девтулсами, активно взаимодействуют с событийной моделью Symfony, с флоу пути запроса-ответа. часто имеют собственный веб-UI вплоть до предоставления единственного UI приложения. Собственно сам фреймворк — лишь бандл. С другой стороны, нередко они лишь тонкие адаптеры к компоненту/бриджу, например, просто регистрирующие сервисы в контейнере и конфигурирующие их в Symfony-way. С последними релизами Symfony (3.4 и 4.0 прежде всего) нужды в таких бандлах стало значительно меньше, регистрацию и конфигурирование можно делать автоматически, лишь "натравив" контейнер на нужную папочку.


                          Бандлы — практически полнофункциональные, пускай и узкоспециализированные, приложения, сильно зависят от фреймворка, очень часто являются пакетами тесной интеграции компонентов или сторонних библиотек в фреймворк. Когда достаточно простые обертки, когда заметно сложнее собственно оборачиваемой либы (полноценное внедрение в девтулсы, например) или имеют свой собственный UI типа бандла для RAD админок. Собственно сам фреймворк — это тоже бандл.

                          • +1
                            Огромное спасибо за информацию. Только получается, мы не отказываемся от фреймворка, а берем symfony. Или берем любой другой фреймворк и подключаем симфони компоненты.
                            • +1

                              С Symfony (особенно текущие версии) можно написать огромное приложение так, что только с десяток (грубо) строк кода (не считая конфигов) будут зависеть от собственно Symfony Framework. Все остальные зависимости Symfony будут от компонентов, многие из которых поддерживают PSR стандарты, а те, что не поддерживают (прежде всего по причине отсутсвия таких стандартов) самодостаточны с одной стороны, а с другой могут быть изолированы за более специфичными для приложения абстракциями. При переходе на другой фреймворк или отказе от фреймворка в принципе, практически не нужно будет переписывать код, только выкинуть связи с Symfony и как-то реализовать ту функциональность, что реализовывалась Symfony.

                              • 0
                                Жду стандарт хлебных крошек :)
                    • 0
                      Наверно, все зависит от задач. Я около 5 лет назад «на коленке» сделал «Телефонный Справочник» для локалки [https://github.com/bigov/phonebook], так там только Smarty для кэширования. Хотя и MVC (вроде как) пытался реализовать, но весьма лаконичный — чисто под конкрентные задачи.
                      • 0
                        Учитывая то, что нормальный MVC требует прямого общения модели с представлением этой модели (т.е. вебсокеты или лонгполлинг), то я бы, например, очень сильно удивился, если бы у вас он получился =))
            • +11
              Обойдемся без фреймворка, просто возьмем:
              • Composer
              • PHP-DI
              • Zend Diactoros

              Готово — мы вывели «Hello, world»!

              Ага, современный бэк — бессмысленный и беспощадный :D

              Лучше уж готовый фреймворк, чем такой борщ из библиотек (которые и не библиотеки на самом деле а микро-фреймворки). И преемственность выше и код понятней и обслуживать проще и документация по всем компонентам сразу.
              • 0
                Для работы да. А для изучения?
                Нет, я конечно понимаю что здесь чисто «как нарисовать сову», но тем не менее…

                Хотя да, по здравости если подумать. Добавил в закладки чисто потому что «потом когда-то решу причухать свой фреймворк и выпустить в паблик, тогда загляну сюда, поменяю часть своих велосипедов на что-то более PSRистое». А так то наверняка бы половину не понял в статье, если бы все это не знал раньше.
                • 0
                  Ну, насколько я могу видеть в статье написано: «следующий проект начниете писать без фреймворков», что как-то идет в разрез с простым обучением, а намекает на работу.
                  • 0
                    Скорее намек на практику, что не идет вразрез с обучением.
                  • 0
                    Для изучения index.php
                    Без зависимостей, для понимания работы роутинга
                    <?php 
                    # Author - Fedor Vlasenko, vlasenkofedor@mail.ru php 7
                    define('METHOD', $_SERVER['REQUEST_METHOD']);
                    define('URI', parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH));
                    
                    function router($url, ...$args)
                    {
                        (empty($args[1]) || false !== strpos(METHOD, $args[0]))
                        && (URI === $url || preg_match('#^' . $url . '$#iu', URI, $match))
                        && die(call_user_func_array(end($args), $match ?? []));
                    }
                    
                    router('/', function () {
                        echo 'Index page';
                    });
                    
                    router('/article/(.*[^/])', 'GET', function (...$args) {
                      echo 'Article: ', $args[1];
                    });
                    
                    header($_SERVER['SERVER_PROTOCOL'] . ' 404 Not Found');
                    echo '404';
                    
                  • 0
                    Что из приведенного отвечает определению микрофреймворка? Какое будет ваше определение? Где грань между фреймворком и вызовом переданных заранее колбеков?
                    • +16
                      Ага, современный бэк — бессмысленный и беспощадный :D

                      А Вы на фронте были?
                      • +5

                        А там ещё беспощаднее.

                        • +8
                          А Вы на фронте были?
                          Так точно! Седьмая джаваскриптовая дивизия, старший корректировщик webpack-a!

                          /joke
                        • +1
                          которые и не библиотеки на самом деле а микро-фреймворки

                          Нет, это именно библиотеки. А Вы не понимаете разницу между библиотекой и фреймворком.


                          Статья — норм, заголовок — вполне точен.


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

                          • +1
                            А Вы не понимаете разницу между библиотекой и фреймворком.

                            Для меня отличие библиотеки от фреймворка в том, что библиотека выполняет четко только одну задачу, микрофреймворк — задачу и смежные с ней (близкие по функционалу).

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

                            Ноу проблем — укажите мне, где я ошибаюсь.

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

                            При этом все, что указывалось как недостаток обычных фреймворков будет точно также.

                            Тогда смысл? :D
                            • 0
                              Смысл — поиграться. Другого смысла нет. Ну или как бутстрап для своего фреймворка, если уж всерьез писать. Если бы в статье было чуть подробнее и понятнее для новичка, и были бы все базовые понятие/PSRы реализованы/прилинкованы, то статья была бы действительно полезной. А так это пока лишь заготовка.
                              • 0
                                «Главное отличие библиотек от фреймворков в том, что фреймворк запускает ваш код, и, в общем случае, контролирует свое собственное окружение; в то время, как библиотека – это нечто, что вы используете из своего кода, контролируя свое окружение самостоятельно»

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


                                • –1
                                  микрофреймворк — задачу и смежные с ней

                                  Нет, смысл совсем не в размере, охвате и пр.


                                  Суть в направлении контроля. Фреймворк вызывает Вас. Вы вызываете библиотеки.


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

                                  Почему это он неуклюжий? Зачем мне шаблонизация, если у меня строго JSON API? Суть — с введением PSR можно самому собрать собственный фреймворк, делающий ровно то, что нужно и ничего больше, из кода разных производителей.

                                  • +1
                                    Интересное определение, а если библиотека вызывает Ваш callback (любой eventer) — она сразу же становится фреймворком?

                                    Тем более разговор был про микрофреймворки, не так ли?

                                    Можно ссылку почитать такое определение для микрофреймворков?

                                    Ибо ИМХО push/pull — это модель работы, но ни как не определение.
                                    Единственное, с чем согласен — что фреймворк (не микрофреймворк) всегда идет со своим окружением, которое он постоянно поддерживает в актуальном состоянии — на то он и «каркас».
                                    • 0
                                      Интересное определение, а если библиотека вызывает Ваш callback (любой eventer) — она сразу же становится фреймворком?
                                      Я бы сказал что всё зависит от «масштабов бедствия»: если подавляющее большинсво кода, использующего библиотеку не является кодом callback'ов, то, конечно нет. От того, что вы callback на три строки в qsort передали libc не станет фреймворком.

                                      А вот если у вас большая часть приложения, общающаяся с библиотекой и состоит из этих callback'ов… тогда да. Скажем GTK обычно позиционируется как библиотека виджетов, но на практике — это скорее фреймворк.

                                      Хотя да, конечно, бывают и пограничные случаи…
                                  • –1
                                    А на самом деле он слепил свой собственный неуклюжий фреймворк,… у него и получится обычный фреймворк, только зависящий от кучи разных библиотек, не протестированных на четкую работу вместе

                                    В этом-то и идея PSRов, что реализуя интерфейс, не нужно тестировать взаимодействие, потому что оно гарантировано контрактом и тестами самой реализации.

                                • 0

                                  Современный фронт ещё более бессмысленный

                                • +1
                                  Когда-то я так пробовал делать, в итоге у меня получился Symfony процентов на 70.
                                  После этого решил, что не зачем выпендриваться — минусов больше чем плюсов.

                                  но для обучения полезно, спору ет
                                  • +2
                                    Для обучения я бы рекомендовал написать свои простые реализации для интерфейсов PSR для простых случаев и без оптимизаций, а не тянуть готовые, где тончайшие нюансы предусмотрены и до доль микросекунд код вылизан.
                                    • 0
                                      Спасибо за туториал, занятно. Общая идея понятна, наверное потому что я её уже знаю, а вот реализация вообще не понятна.
                                      Спасибо за ссылки для дополнительного чтения.

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

                                      Про микро-фреймворки очень справедливое замечание, я знакомился со Slim-ом, он умеет две нужные вещи:
                                      1. роутинг,
                                      2. конвейнер мидлвэер


                                      и больше ни чего, то есть весь функционал того что есть в статье. Свой велосипед делать не надо.
                                      • 0

                                        Что касается луковицы, то я думаю, что метафора скорее относилась к принципу работы pipeline (когда массив middleware сворачивается в рекурсивный вызов через array_reduce), нежели к "луковой архитектуре". И действительно


                                        $response = $middlewareA($middlewareB($middlewareC($request)));

                                        вполне себе "луковица".

                                        • –1
                                          из туториала по Slim:
                                          <?php
                                          $app = new \Slim\App();
                                          
                                          $mw = function ($request, $response, $next) {
                                              $response->getBody()->write('BEFORE');
                                              $response = $next($request, $response);
                                              $response->getBody()->write('AFTER');
                                          
                                              return $response;
                                          };
                                          
                                          $app->get('/', function ($request, $response, $args) {
                                          	$response->getBody()->write(' Hello ');
                                          
                                          	return $response;
                                          })->add($mw);
                                          
                                          $app->run();
                                          

                                          то есть перед вызовом (вместо
                                          $response->getBody()->write('BEFORE');
                                          ) можно как угодно изменить
                                          $request, $response
                                          , так и после вызова — вместо (
                                          $response->getBody()->write('AFTER');
                                          ) можно как угодно изменить
                                          $request, $response


                                          физически оно запускается как луковица, но если подумать то можно сделать последовательную логику работы:
                                          <?php
                                          $app = new \Slim\App();
                                          
                                          $mw1 = function ($request, $response, $next) {
                                          
                                          // business logic BEFORE with mutate $request, $response
                                              $response = $next($request, $response);
                                          
                                              return $response;
                                          };
                                          
                                          $app->add($mw1);
                                          
                                          $mw2 = function ($request, $response, $next) {
                                          
                                              $response = $next($request, $response);
                                          // business AFTER logic with mutate $request, $response
                                          
                                              return $response;
                                          };
                                          
                                          $app->add($mw2);
                                          
                                          $app->run();
                                          
                                      • 0
                                        Осталось добавить сюда минимум то без чего не обойтись в минимальном приложении это ORM, миграции, валидацию, обработку шаблонов для email, отправку email, file storage и… получим то что Laravel предоставляет из коробки.
                                        Без фреймворка хорошо писать только в целях саморазвития для своего личного проекта где вы будете сами это все поддерживать, но для коллективной разработки лучше всетаки использовать фреймворки так как они вносят свои стандарты построения приложений.
                                        • +1
                                          ORM полно однотипных и есть Doctrine. Валидаций куча, мейлеров популярных минимум 2 и всё это гвоздями друг к другу не прибито как в ларе. Стандартизация интерфейсов, низкая связанность и прочие современные тренды позволяют писать приложения, где, грубо говоря, хоть каждый день можно компоненты менять.
                                          • +1
                                            В чем вам легче будет разобратся в самописном коде, или в коде который был написан по стандартам фреймворка? А если код был написан не самым опытным программистом? Вам захотелось бы разбиратся в той архитектуре? А в случае с фреймворком если человек который писал код следовал стандартам, у вас уже будет более менее ясное представление о приложении. А насчет Laravel впервые слышу что там что то прибито гвоздями, наоборот при желании вы можете взять любой компонент и он будет работать отдельно от фреймворка.
                                            • +3
                                              Конечно будет, но за собой потащит ещё половину ядра. Да и некоторая часть просто гвоздями прибита, например тот же шедулер или очереди. А пытаться миддлвари использовать отдельно от ларовского http (была у меня попытка прикрутить их к вебсокетным onMessage событиям) смерти подобно.

                                              Ну т.е. скажем так. Некоторая часть фрейма отлично выдирается: Контейнер, саппорт, пагинатор и проч., а некоторую даже при всём желании адекватно не получится.
                                              • 0
                                                Ну потащит окей, некоторые компоненты зависят от других и код реиспользуется. Это вроде как стандартный подход, любой компонент имеет какие-то свои зависимости.
                                                • +2
                                                  Да то что тащит — это мелочи, хотя те же контракты при подключении саппорта не мало бесят. Особое удовольствие тут в том самом прибитии гвоздями и организации кода. Пытался я вытащить ларовские очереди и переложить их на доктрину. Это печальная история, должен я сказать.
                                                  • –1
                                                    Ну тогда можно не использовать компоненты Laravel не вижу тут проблемы :)

                                                    Мой месадж был о том что какраз эта прибитая гвоздями организация кода и позволяет командам писать код в пределах фреймворка который будет понятен всем. Когда при кастомном решении новому человеку пришедшему на проект надо будет вникать во все ньюансы самописного решения и думать как ему встроить что то новое чтобы не сломать старое.
                                                    • 0
                                                      Так никто не спорит. Я за ларку (и симфони) всеми руками и другими выпирающими частями тела. Я же коммент свой писал в качестве замечания на:
                                                      А насчет Laravel впервые слышу что там что то прибито гвоздями
                                                      да цитирование просто забыл. Теперь будете знать, что не всё в Багдаде спокойно, хотя казалось бы… =)
                                                • 0
                                                  Вот не надо, в ларе гвоздями прибиты три вещи: контейнер, система событий и роутер. Всё остальное, включая упомянутый шедулер и очереди, легко (ну ладно, не очень легко) разруливается написанием своего драйвера.

                                                  P.S. ну и да, доп пакеты типа пасспорта, довольно жестко завязаны на ёлку.
                                                • 0
                                                  Стандарты стандартам рознь. И в целом как раз по стандартам какого-то фреймворка написанный код сильно завязан обычно на этот фреймворк, разбираясь с приложением на незнакомом фреймворки очень значительную часть времени будешь тратить на изучение фреймворка, потому что, например по его стандартам принято создавать и обрабатывать формы по метаинформации из класса сущности. Он позволяет разделять их, но по стандартам не принято дублировать информацию, совпадающую на 99% по содержанию в 99% случаев.
                                            • +5

                                              У меня конечно осталось ощущение переусложненности. Ну например, зачем делать объект "вызываемым" через invoke, когда можно сделать обычный, немагический метод? Ради чего? Такое ощущение, что они используют invoke просто чтобы он был.


                                              Насчет DI контейнера — по моему, Pimple проще. Там определение сервисов делается просто через анонимные функции, без этих громоздких конструкций \DI\create(Some::class).


                                              Зачем нужно тут middleware? По моему, проще роутер просто вызывать напрямую и обойтись тем самым без библиотеки Relay. Или целью автора было использовать очередной PSR?


                                              А так, конечно, я не вижу ничего плохого. В той же Симфони мне например не нравится куча конфигов, модуль security и неявные вещи, вроде всяких обработчиков событий, из-за которых мы не можем легко проследить, как выполняется код, начиная с index.php.

                                              • 0
                                                Да, показалось что автор использовал это только потому, что это существует. Использование ради использования, только потому что это есть, даже если нет необходимости. Это сейчас такой рак мозга у многих, независимо от языка. Именно поэтому банально не смог объяснить, зачем он это всё использовал.
                                              • 0
                                                Мне очень понравилась вводная часть. Я тоже сторонник сборки своего фреймыорка под проект. Но дальнейшая подача материала не стректурирована и не совсем понятно что и для чего мы делаем. Надеюсь, в скором времени накатать свой вариант статьи о сборке проекта из библиотек. Надеюсь у меня получится донести смысл такого подхода. Удачи!
                                                • 0
                                                  Очень даже неплохо, но как то все таки станно видеть как из готовых пакетов собирается собственно микрофреймворк. Как мне кажется, интереснее было бы в рамках обучающей статьи показать более детальный пример работы одной компоненты.
                                                  • +2
                                                    Очень для меня сомнительно утверждение, что явно прописанные инклуды труднее понять и отследить, чем не прописанные в коде явно автозагрузки.
                                                    • 0
                                                      Очень правильно все, кто не понял, у меня для вас плохая новость… Идеальное приложение это комбинация слабосвязанных компонентов наиболее адекватных решаемой задаче. И есть фреймворки двигающиеся в этом направлении, например zend expressive. А symfony, zend и laravel… им спасибо за донорство компонентов )
                                                      • 0
                                                        Где в Symfony сильная связанность?
                                                        • +1
                                                          Вот, кстати, тут у меня тоже есть претензии к symfony: несколько раз пытался использовать из него отдельные компоненты, а в результате у меня через зависимости вытаскивалась половина фреймворка. При таком положении вещей уж лучше его целиком использовать.
                                                          • 0
                                                            Где в Symfony сильная связанность

                                                            Ну на самом деле куча бандлов, идущие как стандартные, представляют собой месиво, гвоздями приколоченное к некоторым основным компонентам (типа Доктрины). Как будто сделано все, чтобы показать, что наличие интерфейсов еще не означает слабую связанность :).

                                                          • 0
                                                            Эм… и вас не смущает что вы в одной фразе соединили обвинение перечисленных фреймворков в повышенной связности и «донорство компонентов»? Совсем-совсем не смущает?
                                                          • +4
                                                            А мне норм. По моему человек имел ввиду не то, что все должны бросить всё и каждый собирать свой велосипед, а то, что современное состояние php с composer и psr изменило понятие «фреймворк». Теперь это не закрытая инфраструктура, а просто набор взаимозаменяемых модулей. А фреймворки превратились в дистрибутивы Linux. И даже не Linux, а Debian/Ubuntu/Kubuntu/Lubuntu/Mint/etc… Т.е. нечно разное, но сильно взаимозаменяемое.

                                                            И относиться к этому надо именно так. И особенно разрабатывать код. И выбор фреймворка не что-то судьбоносное, а просто «мне нравится дефолтный выбор компонентов», «но если что — полностью перепахаю за денёк».
                                                            • 0
                                                              Справедливости ради, приложение нужно писать специально так, чтобы фреймворк сменить было «на день работы», то есть всё важное должно быть от фреймворка отделено, пускай компоненты из фреймворка использовать, но не пользоваться его магией, например, превращающую $_REQUEST в SQL запрос толком даже без описания схемы.
                                                            • –3
                                                              Лучше бы научились обходиться без composer'ов, чем без фреймворков.
                                                              • +5

                                                                Тридцать лет без композеров обходились

                                                                • –1
                                                                  Да и до сих пор прекрасно обходимся.
                                                                  • +4
                                                                    Главное потом не показывать свои «труды» никому.

                                                                    </irony>
                                                                • +2
                                                                  Почему лучше?
                                                                • –3

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


                                                                  Человек, не способный разобраться в чужом фреймворке, сделать на его основе высокоэффективное решение, не сможет создать свое решение, которое превосходит готовый фреймворк хоть в чем-то. Это аксиома.


                                                                  Имеет смысла писать без фреймворка для того, чтобы понять, как оно все работает. На учебных проектах. Можно личный блог написать без фреймворка, или какой-нибудь другой игрушечный проект. Но ни в коем случае не production код.


                                                                  Еще раз повторюсь: я еще ни разу не видел, чтобы человек, строящий велосипеды, смог сделать велосипед лучше существующего. Ни разу. Кроме тех, кто построил уже существующие фреймворки, но эти люди не начинали с нуля, у них уже был огромный опыт, и они понимали зачем строят фреймворк.


                                                                  Кроме того, свой велосипед:
                                                                  а) не будет иметь документации (в 99% случаев)
                                                                  б) не будет иметь тестов (в 99% случаев)
                                                                  в) будет использовать непонятные большинству сторонних разработчиков соглашения об именах, расположениях файлов, конфигурации, и т.д. и т.п.
                                                                  г) не будет совместим с имеющимися батарейками для других фреймворков, всю дополнительную функциональность придется писать всегда с нуля


                                                                  Я помню, как в одном проекте разработчик создал свой мета-фреймворк над фреймворком. Все функции и классы в нем назывались одной-двумя буквой для краткости. Например:


                                                                  T -> render_to_response
                                                                  R -> redirect
                                                                  RV -> redirect_to_view
                                                                  E -> return HttpResponseError()

                                                                  Это все было понятно ему, но когда он ушел из проекта, а на его место взяли меня, мне пришлось выучить около 20-30 этих сочетаний, причем не всегда они именовались логично. А дальше я столкнулся с тем, что он определил несколько модулей utils в разных пакетах, и в некоторых из них однобуквенные функции переопределялись, причем с немного иной семантикой… Тут начался ад, и я постоянно сталкивался с ошибками, так как мало того, что надо было вспоминать, что, например, обозначет RV('people-list'). Надо было еще каждый раз смотреть в начало файла, чтобы посмотреть, из какого именно пакета это сокращение импортируется. Затем надо было вспомнить или посмотреть, что именно делает RV в данном пакете.


                                                                  Через месяц мучений, я выкинул все это, и переписал на обычных вызовах методов фреймворка. Мне не сложно вместо T написать render_to_response, тем более, что сейчас все редакторы и IDE поддерживают autocomplete или дополнение по образцу (Alt-/ в Idea). Зато абсолютно любому человеку, приходящему в проект, сразу понятно, что делает код.


                                                                  TLDR: Изобретать велосипеды очень плохо, всегда получаются квадратные колеса. Всегда.

                                                                  • –3
                                                                    ишо одна шутка про пхп и я звоню в полицию
                                                                    • 0
                                                                      Тоже использую каркас , но как ни крути пришлось много допиливать: консоль, модули, шаблонизаторы и тд
                                                                      • +1
                                                                        • Composer
                                                                        • PHP-DI
                                                                        • Zend Diactoros
                                                                        • Middleware
                                                                        • FastRoute


                                                                        Вам не кажется что Вы изобрели zend expressive?
                                                                        • +1
                                                                          PHP исполняет серверные приложения в цикле запрос/ответ. Всё взаимодействие с приложением — из браузера, командной строки или REST API — приходит в него в качестве запросов. При получении запроса приложение загружается, обрабатывает запрос и генерирует ответ, который передаётся обратно клиенту, а приложение закрывается. И так происходит при каждом обращении.

                                                                          Не всегда, не нужно быть столь категоричным. Не забывайте, что php-приложение может запускаться БЕЗ запроса и при этом ничего не отправлять клиенту, запускается по крону, к примеру, собирает данные из нескольких баз, обрабатывает и складывает их в другую базу. И не стоит забывать, что php-скрипт вполне можно демонизировать, тогда оно завершаться будет только в исключительных случаях.
                                                                          • 0
                                                                            Интерфейсы PSR позволили пойти путем стандартизации и переиспользования кода из коробки.
                                                                            PSR-7 + PSR-15 позволили решать часть типовых задач отвязано от фреймворка X, на котором нравится писать. Самое ценное то, что благодаря стандартизации стало реально заменять реализации и использовать интерфейсы, без написания собственных адаптеров или интеграций. Как выше упоминалось, разработка простого приложения, действительно, сводится к скачиванию пакетов и выстраиванию цепочки их выполнения через PSR-15.
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • +1
                                                                                У автозагрузки есть еще интересный баг, если в коде есть проверки существования класса и т.д. и это все внутри цикла — это будет приводить к проверке file_exists на каждый вызов, а это файловая операция, которая может неплохо так замедлить весь цикл. Например внутри своего автолоадера я сразу впилил небольшой кэш проверок, на случай попытки подключения несуществующих классов. Но иногда подключая сторонние библиотеки ловлю там самостоятельные автолоадеры, которые таки делают постонные лишние запросы на проверку библиотек, которых нет.
                                                                                • 0
                                                                                  Любопытно. Не думал об этом.
                                                                                  Но мне что-то не приходит в голову кейс где будут множественные проверки существования класса, так чтобы не городить уж очень кривое что-то.
                                                                                  Проверка существования класса как по мне должна в случае его отсутствия объявлять ему замену. Других кейсов я не вижу.
                                                                                  Какие-то попытки автоматического внедрения зависимостей по цепочке воркараундов?
                                                                                  Ну это само по себе глупо. Ну в смысле цепочки делать. Пойди найди потом какое из умолчаний у тебя сработало.
                                                                                  Нет, возможно я что-то упускаю. Можете привести пример? Любопытно.
                                                                                  • 0
                                                                                    Например вы в цикле вызываете другую библиотеку, которая в свою очередь при создании объекта таки определяет, какие есть библиотеки через проверку существования класса и " в случае его отсутствия объявлять ему замену. " как раз использует замену. Однако т.к. мы вызываем эту стороннюю библиотеку в цикле с разными параметрами — она постоянно проверяет существование классов. Если файлы находятся на медленном диске, или вообще подключаются через NFS — это может быть очень и очень долго.
                                                                                    • 0
                                                                                      Так а что кешировать тогда если каждый раз новое ищется?
                                                                                      Или вы имеете ввиду не кеширование внутри сессии, а кеширование МЕЖДУ сессиями, типа сохраняем список несуществующих классов в файлик и при запуске автозагрузчика загружаем только этот файлик с отлупами?
                                                                                      • 0

                                                                                        Static-кэш. Чтобы в рамках одной сессии не пробовать попытки подключения того, чего нет.

                                                                                      • 0
                                                                                        Стоп. Но file_exists кешируется. И если вы в том же цикле не вызываете clearstatcache(), то все будет впорядке, пусть даже вы жуткий извращенец и код у вас лежит на NFS (я так делал — все работает).

                                                                                        Вы замеры делали? На сколько это реально тормозит систему?
                                                                                        А то мне это напоминает оптимизацию через одинарные кавычки.
                                                                                        • 0
                                                                                          Ну есть некоторые облачные хостеры (вернее платформы для оного) у которых файлы по сети и это да, превращается в проблему. И даже не совсем облачные а вроде банальный шаред заказывал, но потом тебе рассказывают про облака…
                                                                                          Я раньше пытался бороться с этим, даже удачно. Но сейчас решил что дешевле сменить хостера.
                                                                                          • 0

                                                                                            Лишние операции даже к очень быстрой файловой системе могут быть медленнее, чем к локальному Redis. Причем ФС может быть загружена конкурирующими запросами.

                                                                                          • 0

                                                                                            Может у вас кэшировался — у меня вот нет. У меня быстрые скрипты без фреймворков — там весь скрипт менее чем за 1мс выполняется, причем большую часть занимают запросы к БД. Так вот xhprof явно указывал что выполнялось много лишних файловых операций проверки file_exists из автолоадера.
                                                                                            Сейчас точно не вспомню, но мне кажется в phpmailer была как раз проблема у меня в консюмере, что автолоадер там с ума сходил.

                                                                                            • 0
                                                                                              Возможно как-то зависит от настроек системы. Но я специально проверял эту фичу (file_exists, is_file, is_dir) — и оно правда кешируется. У меня даже есть кейсы сброса этого кеша и там без clearstatcache() никак.

                                                                                              Не знаю на счет кеша в разных сессиях (не проверял), но в пределах одной у меня он всегда работал.
                                                                                              • 0

                                                                                                Может у вас не настроен realpath_cache_size?

                                                                                        • +1

                                                                                          В контексте composer, например, есть несколько уровней вариантов оптимизации автозагрузки: https://getcomposer.org/doc/articles/autoloader-optimization.md. Этот же механизм позволяет легко отлаживать проблемы, которые могут быть вызваны некорректной автозагрузкой классов.

                                                                                        • 0
                                                                                          Сейчас кодить без Фреймворка — это что-то сложное и признак мастерства?

                                                                                          А не получается без фреймворка.
                                                                                          В принципе не получается.
                                                                                          Один раз вкусил и всё. Без него уже не можешь. Как наркотики.
                                                                                          Сколько раз я уже начинал «простенький проект, будем без фреймворка делать». Какой-то MVP-одностраничник, или просто расколупать шаблон перед натягиванием (большой шаблон, типа AdminLTE, но все равно) — чисто разобраться во внутренностях, порезать на куски…
                                                                                          Потом вдруг очнешься посередине, а у тебя уже микрофреймворк написан.
                                                                                          Минимальный шаблонизатор на 20 LOC, минимальный функционал мультиланг на 50 LOC, ассетсы на 20 LOC, сахарная функциональщина ко всему этому на пару дюжин строк, а дальше уже просто не можешь удержаться и не сделать роутер на дюжину строк, и потом в это все внести хоть в структуру MVC. И всё. По сути это уже не «без фреймворка». а пусть и совсем крошечный и не полноценный, но фрейиворк.
                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                            • 0
                                                                                              Ну я не говорю про использование монструозных библиотек.
                                                                                              Но банальный DRY вынуждает писать шаблонизатор. Иначе будет капец.
                                                                                              Потом еще что-то, еще что-то и просыпаешься с готовым фреймворком.
                                                                                              Буквально пару десятков разных страниц, пару дюжин UI-компонент (часто со своими зависимостями) и всё, приехали. Разобраться в портянке невозможно.
                                                                                              CSS на полсотни килобайт листать для каждой правки. Потом потерянный мертвый код, ад зависимостей (всякие js/css библиотеки… кому они нужны? Может я уже удалил это давно? А что это за css-класс такой? Где он используется?).
                                                                                              Начинаешь таки упорядочивать.
                                                                                              Хоть минимально чтобы css/js и подгрузка внешних файлов для них лежали в одном месте с шаблоном который их использует. И компилировались на лету.
                                                                                              А значит уже минимальный ассет-менеджер.
                                                                                              Потом понимаешь что все равно придется делать двуязычную версию. Да и клиент захочет править всякие строки отдельно, не заглядывая в код.
                                                                                              Выносим все строки в json-ы к одноименным шаблонам.
                                                                                              Готов еще один класс в наш фреймворк.
                                                                                              Нет, нет, я не буду писать роутер. Нет, у меня только одна страница всего. Ну хорошо две, языки еще разные, но я могу это одной строчкой написать.
                                                                                              Ну ок, есть еще чуть другой интерфейс для админа, но что ради этого роутер писать? Не буду! Статические файлы? Кишки «фреймворка» спрятать в хтаксесс? Все равно не буду. Черт, еще форма фидбека и страница ЧАВО. Ну хорошо, хорошо, пять строчек роутера это не фреймворк…
                                                                                              Контроллеры? Ну блин, есть же контроллеры в ангуляровской части! Ну ладно, ладно, напишу, а то будет как с роутером.
                                                                                              Черт, как все-таки удобно когда формы генерятся из модели автоматом. И валидация…
                                                                                              Даже и не думай! Не думай я тебе сказал!

                                                                                              Вот как-то так было у меня в голове крайнюю неделю.
                                                                                              И то что вышло в итоге — уже микроскопический, но фреймворк.
                                                                                              Ну не получается у меня без фреймворков. Не получается.
                                                                                              • +2
                                                                                                Заголовок спойлера
                                                                                                image
                                                                                                • 0
                                                                                                  В большинстве сайтов есть какая-никакая работа с СУБД, есть формы (в том числе с файлами), есть валидация, есть защита от инъекций, есть какой-то роутинг (пускай и на уровне php-файлов), есть конфиги, часто есть аутентификация и авторизация, нередко есть отправка почты и скрипты CLI (например для крноджобов). Кэширование. Это только навскидку.
                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                    • 0
                                                                                                      не надо разбираться с фреймворками, который каждые пару лет меняются и помирают, в которых находят дыры и надо держать руку «на пульсе» чтобы сайты на их основе не подвергать риску

                                                                                                      Этому явлению есть давно устоявшееся название: «Неуловимый Джо» называется.
                                                                                                      Есть такая известная атака из класса «человек посередине». Подобную уязвимость находили во многих фреймворках. У вас не находили.
                                                                                                      Атака заключается в уводе сессии или просто XSRF вскрывая токен безопасности манипулируя юзерконтентом и анализируя степень сжатия страницы.
                                                                                                      Как у вас с этим? Наверняка продумали...)
                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                        • +2
                                                                                                          Ну т.е. ваш сайт в принципе спокойно вскрывается «человеком посередине», даже при сертификатах с А+. Прекрасно. Уровень среднего фреймворка годов этак 2012-2013. Да, да, 2013. Я правильно угадал. Тот же BREACH например стал общеизвестным именно в этом году, и именно тогда большинство фреймворков от нее закрылись. Некоторые чуть позже.
                                                                                                          Ну и я не стану придираться к «У меня SSID генерится на основе useragent+remote_ip (и немного соли, но не суть)». Предположим что вы просто неудачно выразились, а имели ввиду нечто иное.
                                                                                                          У меня несколько иной чем у вас уровень проработки подобных вопросов, но я уверен что если бы я выкатил свой фреймворк в паблик то сразу бы получил парочку пулреквестов по безопасности. Вот 100% уверен!
                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                            • 0
                                                                                                              Простите, но я не готов сейчас проводить ликбез по основам сетевой безопасности. В 2018-м году блин. Пятница. Простите. Если вы не загуглили ключевое слово из прошлого сообщения, то вы не загуглите его и сейчас. И… вот я же знаю всё что вы скажете. И не будете вы ничего читать, и ничего слушать. Но ладно. Я таки повторю это одно слово. BREACH. Всё. Ну елки палки. Ну просто же.
                                                                                                              Вот каждая фраза в вашем комментарии. Каждая. Отстает лет на пять от современного веба. Ай, ладно. Пошел я пить в общем…
                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                • +1
                                                                                                                  Кажется вы не читали: https нет

                                                                                                                  Еще раз. Восстановим логическую цепочку. Наш спор начался с того что я вам сказал что вы Неуловимый Джо. Дальше в принципе можно не продолжать. В «молодости» регулярно осуществлял MITM. Это было еще во времена махрового диалапа. То таки да линию слушали, чего уж там. То знакомый у провайдера работал, с коровского маршрутизатора сливали. То еще что.
                                                                                                                  Бывало и наоборот. Аську мою шестизнак именно через MITM увели. Про корпоративные сети/точки доступа я в принципе молчу как и про интернет-клубы.
                                                                                                                  В эпоху вайфая… просто вайфая, не обязательно публичного/бесплатного — говорить о том, что я защищен настолько что MITM мне не важен, значит быть Неуловимым.
                                                                                                                  Я не буду с вами спорить, объяснять и т.п.
                                                                                                                  Я помню как мне объясняли примерно тоже самое.
                                                                                                                  Это было аккурат в 2007-м. Сейчас стыдно. Но есть понимание почему стоит таки закончить спор.
                                                                                                                  ПС: дизайн конечно зачетный. Даже без учета что тогда это было не настолько ретро. Жаль что эту мешанину из невалидного кода построенную на таблицах не очеловечить (я понимаю, 2007-год, без сарказма, тогда оно было норм). Так бы клянчил шаблон в паблик).
                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                  • 0

                                                                                                                    "сколько сил вы затратите на подмену IP (либо отправку от клиента) и выуживание инфы из кук конкретного браузера у пользователья?"


                                                                                                                    Очень часто в условиях дороговизны IP адресов тысячи пользователей сидят под одним IP адресом за NAT или прокси — коллеги, семья, соседи. И довольно часто именно они заинтересованы в доступе к личной информации типа переписки, с одной стороны, а, с другой, имеют множество возможностей для применения методов социальной инженерии, чтобы получить заветную куку, вплоть до физического доступа к девайсам.

                                                                                                                    • +1
                                                                                                                      Ну физический доступ к браузеру для увода куки это уже клиника. Тут ничего не поможет. А так то банально получить контроль над роутером и вперед. У многих в ноутбуке сохренены десятки вайвай сеток знакомых, работы. Много чего еще.
                                                                                                                      Внедриться посередине на сегодня вообще не проблема. Если раньше надо было иметь доступ к сети провайдера (не всегда, но хорошо бы), то сейчас всегда есть возможность внедриться.
                                                                                                                      А вот провайдерский NAT даст не так много возможностей. Ну в плане того что да, у меня шаред-айпи, да у всех моих соседей по дому тот же айпи. Да, некоторые из них могут социальной инженерией затащить меня на сайт с которого были вызовы разных страниц. Но ответа то нет. И даже по стороннему каналу (размер ответа) тут не получить информацию.
                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        • +1
                                                                                                                          Еще раз — вы Неуловимый. Если бы кто-то из вашего окружения, коллег, знакомых хотел бы вас вскрыть, то они бы спокойно вскрыли. Можно дать вам свой пароль от вайвая. А там уже правильный роутер. Можно банально знать пароль от какой-то точки которая у вас сохранена, погасить «безопасную» сеть в вашем окружении (РЭБ даже не обязательно понадобится — можно тупо незаметно отключить питание на роутере или еще чего), и ваш ноут поймает подставную точку с таким именем и паролем как у той, другой, у общего знакомого, который давал вам пароль, и атакующему давал.
                                                                                                                          Существует очень много векторов атаки с человеком посередине. И как правильно вам сказали — очень часто интерес к доступу к вашим данным может быть не у далекого пользователя, а у человека имеющего с вами физический контакт — коллега, сосед, родственник… Нет, если мы говорим о админе говносайта или красивого хомяка с ретро-шаблоном, то да, тут кроме как автоматическим сканерам уязвимостей вы не интересны никому. Но если это живой проект. Не Неуловимый, то всё. Без сертификата жизни нет.
                                                                                                                          И речь не только о банках, ERP и т.п. Почта, социалки, форумы… все что угодно. А хомяки, простенькие статейники и т.п. — да, они никому не интересны, и атаковать никто не будет.
                                                                                                                          Ну а когда разработчик переходит во взрослую жизнь, то вот эта вся неуловимость быстро заканчивается…
                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                            • +3
                                                                                                                              Вы при помощи внешних относительно сайта действий смогли лично для себя добиться уровня безопасности, который не очень сильно ниже чем у среднего нормального сайта. Пользователи — говно. Пусть сами думают. Серьезный взлом? Ну я же не банк. Все что угодно лишь бы не делать как положено. Все что угодно лишь бы оставаться на уровне технологий десятилетней давности. Ну круто, чё.
                                                                                                                              Вообще, крайне не ясно как обсуждение «без фреймворка можно все реализовать точно такое же, но за чужим кодом надо следить в плане обновлений в силу их распространенности» скатилось что я — Неуловимый Джо. Вы хотите поспорить что можно все написать без фреймворка? Или то что реализация в нем сильно отличается от своего кода настолько, что «безфреймворковский» код априори более дыряв?

                                                                                                                              Можно написать «без фреймворка», просто выйдет свой фреймворк. Без вариантов. И реализация в фреймворках примерно такая же. Только в несколько раз больше вещей продумано. И продумали они не потому что какие-то особенные люди их пишут, а потому что больше опыта, больше людей пишут, больше пулреквестов присылают или уязвимостей находят. У них просто больше ресурс.
                                                                                                                              Писать без фреймворков конечно можно. Когда у тебя уже есть большой пул своего кода, который учитывает большое колво нюансов, написан с учетом регулярного переиспользования, имеет хорошую инкапсуляцию (по степени коровости, по уровням абстркции, по разному функционалу и т.п.).
                                                                                                                              Тогда ты можешь взять этот свой бутстрап, дописать то что нужно в этом проекте и все будет ок.
                                                                                                                              Да, если кто-то возьмет проект после тебя, то у него будет головная боль, но часто это допустимо.
                                                                                                                              Проблема в том, что реально это и будет фреймворк. Только свой.
                                                                                                                              А процедурная лапша написанная каждый раз почти с нуля для каждого проекта, без тестов, без документации, с ограниченным функционалом и т.п… Ну это для обучения/развлечения. Нет, можно и на вордпрессе писать. Он хоть неплохо отлажен.
                                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                  • +1

                                                                                                                                    Синтаксический сахар — это, скорее, библиотеки. Фреймворк — это, всё же, имплементированный набор архитектурных решений, в рамках которого создаётся приложение.


                                                                                                                                    Если вы новое приложение начинаете с пустого каталога, в подкаталог lib которого постепенно по мере надобности копируете прошлый наработки типа роутеров, валидаторов и т. п. (при этом они друг от друга не зависят), то это не фреймворк. Если же вы копируете прошлый проект, удаляете из него всё специфичное для прошлоги и ненужное в новом, а потом в основном дописывате нужную функциональность, не меняя общий поток данных, используя те же умолчания, те же, пускай и немного подправленные конфиги и т. п., очень грубо, оставляете тот же index.php, изменяя только то, что он внутри себя вызывает, оставляете ту же структуру каталогов, на которую ваш код рассчитывает для, например, вычисления полного имени шаблона как './templates/' . $action_name, то ваши наработки — суть фреймворк, а не просто набор библиотек, которые часто переиспользуются в разных проектах.

                                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                      • 0
                                                                                                                                        Теоретически да, но как же обновления?
                                                                                                                                        Уже на второй дюжине проектов ядро будет переписано так, чтобы повысить его инкапсуляцию, чтобы было проще обновлять. вот нашли багу у себя. И что с прошлыми проектами? Должна быть четкая граница между прикладным кодом и ядром. Желательно конечно в контексте композера.

                                                                                                                                        Ну и граница «копируешь нужные либы» и «копируешь проект целиком» не очень формализована.
                                                                                                                                        Ведь индекс.пхп тоже может быть либой).
                                                                                                                                        Мне больше нравится определение: отделен от прикладной логики и создает окружение, а не вызывается из окружения.
                                                                                                                                        Тут более формализовано.
                                                                                                                                      • 0
                                                                                                                                        Так где? Где ваш опыт? Знание низкоуровневых вещей?
                                                                                                                                        Изначальный мой тезис был в том, что если этот опыт есть, то что не делай, у тебя все равно фреймворк выйдет. Ты отделишь ядро для переиспользования. Ты сделаешь компоненты удобными для тестирования и т.п. Понимаешь как важны стандарты. Начинаешь с PSR-1/2/4, потом и прочие подтягиваются. Будешь регулярно добавлять разные вещи, в том числе и защиту от BREACH и прочего.

                                                                                                                                        В ответ я слышу привет из девяностых. Мол хттпс не нужен, это лишнее. Так где ваш опыт то?
                                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                          • 0
                                                                                                                                            А что сложного с роутером то?
                                                                                                                                            В любом роутере есть возможность или свой ДНС прописать или указать конкретные данные для конкретных доменов. Тут в принципе любой эникейщик справится.
                                                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                              • 0
                                                                                                                                                Да тут тысячи кейсов есть.
                                                                                                                                                Можно банально положить родной роутер и поднять рядом свой. С теми же данными доступа. Или даже не с теми. А с любыми какие есть у вас в сохраненных.
                                                                                                                                                Этого достаточно.
                                                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                  • 0
                                                                                                                                                    А какая разница? Вы совершаете классическую ошибку безопасности. Вот этот конкретный случай безопасен, а то что целый класс родственных вещей вокруг в одном месте — нас не интересует.
                                                                                                                                                    Положить роутер? Ну кнопочку ресет зажать на две секунды, пока вышел в туалет (или хозяин в туалет вышел, не суть). Физически заменить на той же марки, только с другими настройками… Да мало ли вариантов? В каждом конкретном случае будет свое решение. Я ведь не говорю о чем-то требующем каких-то минимальных усилий, типа врезаться в ваш провод (в 70% случаев ничего и не надо, просто показываем на одном интерфейсе МАС клиента, на другом МАС провайдерского роутера, и перекидываем все с одного на другой попутно глядя что нам интересно).
                                                                                                                                                    Вся ваша защите строится на приемлемом уровне неуловимости, и в современном мире этот уровень очень низкий. Буквально какие-то хомпейджи и не более. Все остальное уже могут и будут ломать. Нет, всегда можно сказать «клиент сам дурак», и так оно и будет — видел ведь что у вас сертификата нет, а зарегистрировался. Но… непрофессионально.
                                                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                      • 0
                                                                                                                                                        Ой!
                                                                                                                                                        Я думал у вас уровень Милторга.
                                                                                                                                                        А тут совсем школота.
                                                                                                                                                        Ок. Из простенького, что сразу в глаза бросается — у вас XSRF везде. Под рукой нет ни одного тестового домена без https, так что дать рабочую ссылку не могу, но от своего имени я проверил.
                                                                                                                                                        Демонстратор выглядит например так:
                                                                                                                                                        <form action="http://desksoft.ru/index_r.php?inline=mchat" method="post">
                                                                                                                                                          <textarea name="mchat_rep">Hello World!</textarea><br>
                                                                                                                                                          <input value="Send" type="submit">
                                                                                                                                                        </form>
                                                                                                                                                        

                                                                                                                                                        Я так понимаю там еще баг с редиректом назад, по идее если будет незащищенный хост в который класть закладку, то будет норм. Но в любом случае такие вещи кладут в невидимый ифрейм и отправку формы делают из жс, так что даже в таком виде вполне нормально работает.
                                                                                                                                                        С учетом вашего уровня знаний я уточню:
                                                                                                                                                        Для взлома человека залогиненного на вашем сайте нужно чтобы он зашел на какой-то сайт, где будет данный експлоит.
                                                                                                                                                        В целом можно почти любые действия организовать.
                                                                                                                                                        Рассылка в личку, смена пароля и т.п.
                                                                                                                                                        В целом это основы. Что очень хорошо показывает насколько можно быть неуловимым. Галочка «запомнить» есть, так что пользователи с живой сессией тоже есть. Были бы вы кому-то интересны, вас бы уже давно вскрыли.
                                                                                                                                                        Ну и собственно весь остальной ваш бред про то что все вокруг ничего не понимают, один вы в танке — из той же оперы.
                                                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                          • +1
                                                                                                                                                            Ну я в целом такого и ожидал. Другого ответа кроме «это не баг, это фича» от вас ждать не приходилось.
                                                                                                                                                            • 0
                                                                                                                                                              Вот пример: http://jsfiddle.net/ar0aLcLu/

                                                                                                                                                              Допустим, есть пользователь, который при логине на ваш сайт поставил галочку «Запомнить меня». Некто отправляет ему ссылку «посмотри». По ссылке открывается страница с котиками и с кодом, который выше. И пользователь выполняет некое действие на сайте, даже не подозревая об этом — отправка сообщения, изменение пароля, отправка платежа. Это в чистом виде XSRF.
                                                                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                • 0
                                                                                                                                                                  Так речь не о перехвате сессии администратора. Речь о наличии уязвимости на сайте, которая предусмотрена в фреймворках.

                                                                                                                                                                  Максимум можно сделать все то, что доступно текущему залогиненому пользователю. Если вы залогинены администратором и откроете ту ссылку, сообщение будет от вашего имени. Именно поэтому вы и являетесь Неуловимым Джо, так как у вас функционала-то и нет, чужие мессаги не нужны никому.

                                                                                                                                                                  Неважно, какая у вас проверка в формах, если это не аналог CSRF-токена на каждый запрос. Можете подробнее ее описать? Подозреваю, что и ее можно обойти аналогично.
                                                                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                    • 0
                                                                                                                                                                      Ага, ну это аналог. То есть вы потратили время, чтобы придумать и протестировать то, что уже было сделано и можно было сразу использовать.

                                                                                                                                                                      1 день, каждую форму? Вот еще один плюс фреймворка. При правильной организации кода токен проверяется в одном месте. Создается тоже в одном, в какой-нибудь функции beginForm(). Контролируется флагами. Проставить флаги для нужных действий дело нескольких минут. А с учетом того, что проверка csrf есть по умолчанию, надо просто найти и убрать все выражения вида 'enableCsrfValidation = false'
                                                                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                        • +1
                                                                                                                                                                          Да любого. Все современные фреймворки имеют такие компоненты.
                                                                                                                                                                          Laravel Yii2 Symfony Zend

                                                                                                                                                                          хорошая тренировка
                                                                                                                                                                          Для тренировки можно много чего сделать, но для рабочих проектов это не подходит. Фреймворки люди используют не чтобы 'играть в «ООП ради ООП»', а чтобы не тратить время на реализацию того, что уже реализовано, и не исправлять ошибки, которые уже исправлены. А чтобы всем этим управлять, используется то, что описано в статье.
                                                                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                            • 0
                                                                                                                                                                              Однако недопустимо опускаться до уровня «мы ничего не сможем сделать без фрейма»
                                                                                                                                                                              ИМХО, есть зависимость от времени на задачу. Если стоят весьма и весьма сжатые сроки — то сделать быстро и качественно, без фреймворка, может быть если не невозможным, то точно крайне затруднительным (чтобы сделать и безопасно, и тестами, и не говнокод, итд).
                                                                                                                                                                              • 0
                                                                                                                                                                                По-моему по контексту вполне ясно, что человек имел в виду привыкание к хорошей архитектуре и возможностям, а не принципиальную невозможность.
                                                                                                                                                                                Про уровень «мы ничего не сможем сделать без фрейма» там вообще ничего нет. Наоборот, речь идет о полностью своем коде, который получается похожим на фреймворк, а не об использовании известного фреймворка. Так что логическую цепочку переворачиваете вы.
                                                                                                                                                                                Можно? Можно. Просто никому не нужно. Ну кроме тех, кто не захотел хотя бы в одном фреймворке разобраться. Поэтому они используют «свой движок для сайтов», который по факту тоже фреймворк, только с очень ограниченным функционалом.
                                                                                                                                                                                • 0
                                                                                                                                                                                  который по факту тоже фреймворк

                                                                                                                                                                                  Если бы. Я уверен что там под капотом жуткий WET, процедурщина в лучших традициях вордпресса (что тогда было уместно, но не сейчас), и гремучая смесь логики и представления.
                                                                                                                                                                                  Я думаю что то что там под капотом фреймворком можно назвать с большой натяжкой, ибо с таким подходами к архитектуре какие мы тут слышали — закладывать переиспользование кода человек явно не умеет.
                                                                                                                                                                                • 0
                                                                                                                                                                                  и сказал это тот самый человек, который

                                                                                                                                                                                  Ну да. А еще этот самый человек в свое время находил закладки в обслуживаемой им инфраструктуре которые ставили СБУшники. А еще у этого человека в его собственном фреймворке XSRF нет, и проблем с «пользователи жаловались что в разных окнах...» тоже нет, поскольку этот самый человек чуть знаком с тем как работают сами уязвимости, аналитикой по этому поводу, и знает что не стоит дуть на воду с кучей «всегда новый токен», и ради этого оставлять кучу уязвимостей.
                                                                                                                                                                                  Т.е. человек утверждает что без них абсолютно никуда.

                                                                                                                                                                                  Именно. Именно это и утверждает, да.
                                                                                                                                                                                  Цитата из начала треда, где я это утверждаю:
                                                                                                                                                                                  Сколько раз я уже начинал «простенький проект, будем без фреймворка делать».

                                                                                                                                                                                  Потом вдруг очнешься посередине, а у тебя уже микрофреймворк написан.

                                                                                                                                                                                  Не говнокод, который пишут
                                                                                                                                                                                  инвалиды-формошлепы какие-то

                                                                                                                                                                                  а именно фреймворк, потому что даже когда решил по быстрому что-то набросать, руки уже сами пишут DRY и SOLID.

                                                                                                                                                                                  и да, не стыдно писать говнокод. Все когда-то говнокодили, и все мы (ну кроме вас конечно) через некоторое время глянув на свой текущий код будем испытывать стыд, что такое писали. Это норма.
                                                                                                                                                                                  Ненормально застревать в этом говне.
                                                                                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                                    • –1
                                                                                                                                                                                      Похоже СБУшники ваши сами не далеко ушли

                                                                                                                                                                                      Недалеко ушли от кого? От вас? От меня?
                                                                                                                                                                                      Ну да, они использовали довольно простую уязвимость.
                                                                                                                                                                                      И да, я также само как и вы упирался, мол «да нет там никаких дыр, явно люди сливают». Но все равно проверил. И нашел. Не то, чтобы это был прям какой-то серьезный уровень, я бы даже сказал что не большой, но в отличии от вас кое-какой реальный опыт в безопасности у меня есть, да.

                                                                                                                                                                                      А вообще этот тред, хоть и «несколько затянулся», и думаю именно за это мне прилетают «то о чем нельзя говорить», но очень психологии.
                                                                                                                                                                                      Вам объяснили где у вас проблемы с безопасностью. Вы возразили мол безопасность канала вообще не нужна. Вам дали кейсы. Вы сказали мол «все это сложно, а кто говорит что просто — выпендривается». Ок, вас ткнули носом в простенькую уязвимость в вашем сайте. Вы сказали что это не баг, а фича. И вообще оппонент не понимает что такое XSRF. Ну и вишенкой на торте — оценка квалификации особистов, причем со слов, в ситуации о которой вы вообще не в курсе. Браво!
                                                                                                                                                                                      Так толсто, что даже тонко. А мы упорно продолжаем что-то доказывать, объяснять…
                                                                                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                                        • 0
                                                                                                                                                                                          И я сказал что изъяны в безопасности для указанных сайтов допустимы

                                                                                                                                                                                          Ну мне то вы сказали, да. Но я не нашел на сайте предупреждения о том, что поскольку вы умеете писать без фреймворков, то возможность выполнения любых действий любым пользователем, от их имени на этом сайте является допустимым.
                                                                                                                                                                                          К тому же шифрование вы быстренько поломали (BREACH), потому от него толку нет

                                                                                                                                                                                          Ну я встречал велосипеды в которых BREACH закрыта. А так то все фреймворки закрыли эту уязвимость еще в 2013-м.
                                                                                                                                                                                          BREACH я упомянул лишь потому что она с одной стороны достаточно известна, с другой стороны велосипедисты про нее часто не знают. При этом она проста, и вполне себе реализуема «в быту».
                                                                                                                                                                                          Я не говорю об относительно взрослых вещах вроде того почему в пхп появилась функция password_verify.

                                                                                                                                                                                          Почему ваш сайт просуществовал с такой огромной дырой двадцать лет? Потому что вы Неуловимый.
                                                                                                                                                                                          Почему дырЫ вообще появились? Потому что вы:
                                                                                                                                                                                          а) пишете без фреймворков,
                                                                                                                                                                                          б) не имеете достаточной квалификации чтобы писать без фреймворков.
                                                                                                                                                                                          Всё.
                                                                                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                                              • 0
                                                                                                                                                                                                Надо было таки написать что нет, не буду спрашивать. Ну раз не написал, то уже поздно. Не интересно сколько ботов заходит. Это показывает только то насколько популярен сайт с точки зрения некоторых поисковиков.
                                                                                                                                                                                                Да и в принципе о чем можно говорить если дыра на виду, и владелец сайта считает что это не баг а фича?)
                                                                                                                                                                                                все ваши попытки за последние дни увеличили ежедневный лог атак в полтора-два раза

                                                                                                                                                                                                Вот это да, любопытно. Учитывая что попыток как таковых в принципе не было. Отсутствие защиты от XSRF я заметил сразу, когда заглядывал на верстку, на вопрос того можно ли что-то почерпнуть. Так что попыток как таковых и не было. Просто открыл в браузере код страницы, скопировал форму в жсфидл, убрал незначащие атрибуты, нажал кнопку, браузер отказался переходить в связи со смешанным контентом, так что к вам она не прилетела. Следующее действие было с своего тестового поддомена, она была удачной, и собственно все. Т.е. ровно одна запись в логе увеличила колво атак в полтора-два раза. Итого выходит в среднем менее одной атаки в день? Маловато как-то. Я думал сайт более посещаемый.
                                                                                                                                                                                                • 0
                                                                                                                                                                                                  Я подозреваю, там просто хабра эффект сработал. Товарищ весьма опрометчиво провоцирует исследователей, не подозревая пока о возможных последствиях.
                                                                                                                                                                                                  • 0
                                                                                                                                                                                                    А какие могут быть последствия?
                                                                                                                                                                                                    Он же уже прямо сказал что он Неуловимый. Что все что там есть он спокойно вытирает. Бекап наверняка есть.
                                                                                                                                                                                                    Последствий не будет.
                                                                                                                                                                                                    XSS он худо-бедно закрыл. Может не везде конечно, но и без того дырявых сайтов хватает.
                                                                                                                                                                                                    Увод клиентских аккаунтов? Ну да, у смены пароля тоже нет XSRF-токенов, но ведь он прямо сказал что пользователи его не интересуют. Увести его акк?
                                                                                                                                                                                                    Ну если он наврал что ходит через отдельное соединение, то возможно. Но опять же — бекап решает.
                                                                                                                                                                                                    Нет, можно вскрыть его капчу, благо для таких капч есть готовые библиотеки, да и вполне вероятно что есть и другие уязвимости у нее. Тогда можно спам рассылать будет. Но… да кому оно надо с этим играться? Хостер быстрее забанит его, чем ты вскроешь капчу…
                                                                                                                                                                                                    Ну нет там ничего кроме идеи.
                                                                                                                                                                                                    Верстка ужасна. Да и если бы была нормальная — проще сохранить хтмл и разметить под себя, чем разбираться в чужом коде.
                                                                                                                                                                                                    Может SQL-иньекция есть. Наверняка там только самые примитивные методы используются. Наверняка без PDO (а уж свои параметризированные запросы делать он точно не способен), так что если покурить, то наверняка можно будет что-то придумать. Но… результат какой? Откатит из бекапа и будет дальше рассказывать о том какой он неуловимый.
                                                                                                                                                                                                    Не думаю что кто-то еще найдется такой же отмороженный как я, чтобы колупаться.
                                                                                                                                                                                                    • 0
                                                                                                                                                                                                      Согласен. Но сегодня и уже давно взламывают не только тех кто интересен, но и тех кто просто не волнуется. Цели взлома могут быть например создание ботнетов или майнинг или использование чужого сервера для атак на реальную организацию для заметвания следов и т.д.
                                                                                                                                                                                                      • 0

                                                                                                                                                                                                        Я вот одного не понимаю — а что, во фреймворках никогда дыр не находили?

                                                                                                                                                                                                        • 0
                                                                                                                                                                                                          В том то и дело что находили. Находили и закрывали.
                                                                                                                                                                                                          Примерно сразу. Например многократно упомянутый тут BREACH был найден у всех без исключения фреймворков. в 2013-м. И у всех же был закрыт. Примерно тогда же.
                                                                                                                                                                                                          Сейчас 2018-й год, и чувак рассказывает о том, что XSRF во всех формах клиентов включая смену пароля это фича такая, ведь он не смог придумать удобный вариант защиты а потому защитил только админку… в 2018-м. XSRF. Не баг, а фича. Если мы говорим о любом адекватном фреймворке то такого у них нет лет пятнадцать как минимум.
                                                                                                                                                                                                          • –1
                                                                                                                                                                                                            Но ведь на это действительно можно смотреть иначе:

                                                                                                                                                                                                            1. Кому понадобится внедряться в хостинг / провайдер / постороннюю квартиру для организации MitM против простенького сайтика?

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

                                                                                                                                                                                                            И да, насколько мне помнится, достаточно долгое время XSRF очень многими гигантами индустрии и программирования расценивался именно как фича, а не баг. Ибо, протокол позволяет. И какое-то время лишь немногие пытались донести до масс опасность данного механизма, показывая первые PoC успешных Clickjacking-атак. Приблизительное сравнение, которое можно привести — это скимминг. С одной стороны, производители банкоматов, конечно, стараются идти пользователям на встречу и выдумывают программные и аппаратные методы защиты от него, ну а с другой, злоумышленник может связать пациента, приставить паяльник, и узнать пин-код вне зависимости от защищённости банкомата — тут проблема решается сменой стандартов и протокола, чтобы нельзя было на его уровне просто так взять, и подделать карту. Что никак не отменит ситуацию с паяльником.

                                                                                                                                                                                                            2. Целиком полагаться на чужой код, несколько наивно. Не так давно случившийся новогодний коммит в OpenSSL должен служить тому хорошим подтверждением. В критических приложениях автор должен знать и понимать, что делает каждый байт его приложения, и уметь очень оперативно устранить возникающие ошибки на любом слое абстракции, чего с фреймворками достичь проблематично, ибо пока выучишь один фреймворк вдоль и поперёк, он успеет сдохнуть и родится три новых. Если бы в NASA писали на фреймворках, то, боюсь, до сих пор ни одного спутника запущено бы не было, всё ждали бы, пока программисты доведут прошивку до production-ready: «ну вот чуть-чуть ещё подождите, вендор должен исправить такой-то баг фреймворка в следующем релизе.»

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

                                                                                                                                                                                                            3. Проблема обновления и поддержки. Nuff said. Свой код можно обновлять по мере необходимости и атомарно. А вот вылез какой-то страшный баг во фреймворке, и ты сидишь и думаешь — как же теперь эту сборную солянку из непонятных библиотек, полных магии, обновлять? — ибо всё начинает рассыпаться. Rolling release — это модель для отчаянных, готовых в любой момент ринуться в бой с напильниками для костылей. А серьёзные дяди любят, чтобы продукт обновлялся как можно реже, и продолжал свой жизненный цикл как можно дольше, что снизит общие затраты на его R&D. Посмотрите, например, на версии ядер у Enterprise-дистрибутивов Linux. Понятно, что они там многое бэкпортируют, но стремись они за модой, то не смогли бы обеспечить обратную совместимость, стабильность и оперативность исправления критических ошибок в своих продуктах.

                                                                                                                                                                                                            В общем, дискуссии о фреймворках несколько глупы, на мой взгляд. Куда интереснее дискутировать о жизненном цикле и проблемах роста приложений.
                                                                                                                                                                                                            • 0
                                                                                                                                                                                                              Так ведь для XSRF-атаки никуда внедряться и не нужно. Просто оставляем ссылку на форуме — и собираем урожай чужих аккаунтов.

                                                                                                                                                                                                              Насчет нужности тоже все просто. Если на форуме хоть кто-то сидит — значит, он ему нужен.
                                                                                                                                                                                                              • –1
                                                                                                                                                                                                                Ну так и от паяльника никуда не деться. Просто становимся публичным надоедливым для власти и/или мафиози лицом, и собираем урожай угроз и насилия.

                                                                                                                                                                                                                Ещё раз — не стоит спихивать несовершенство протокола на язык или фреймворк.
                                                                                                                                                                                                                • 0
                                                                                                                                                                                                                  Да плевать на то чье несовершенство.
                                                                                                                                                                                                                  Есть задача — сайт должен быть написан быстро, и его характеристики (в том числе и безопасность) должны не слишком уступать большинству современных сайтов.
                                                                                                                                                                                                                  Фреймворк — быстро, минимум глюков.
                                                                                                                                                                                                                  Велосипед — медленно, много глюков.
                                                                                                                                                                                                                  А чье несовершенство — уже не важно. Вообще не важно.
                                                                                                                                                                                                              • 0
                                                                                                                                                                                                                Кому понадобится внедряться в хостинг / провайдер / постороннюю квартиру для организации MitM против простенького сайтика?

                                                                                                                                                                                                                Ну примерно с этого все и началось. Антонн утверждал что у него все чики-пуки и без фреймворков, и без нормальной квалификации, я говорил что лишь постольку поскольку никто его и не ломает.
                                                                                                                                                                                                                А кому надо? Ну вот есть у Антона форум, есть личка там. Решит муж или жена посмотреть с кем и о чем в личке на этом форуме переписывается благоверный… ну или коллега захочет узнать секрет о том, как в Делфи что-то сделать. А секрет ему гуру Антонн в личке написал. Мало ли?
                                                                                                                                                                                                                И да, насколько мне помнится, достаточно долгое время XSRF очень многими гигантами индустрии и программирования расценивался именно как фича, а не баг.

                                                                                                                                                                                                                На Хабре тоже было. Помню смотрел, увидел что есть, попробовал. Не сработало. Забил. Через год вижу статью. Кто-то не забил, расколупал, что оно работало только если запрос аяксовый). Но!
                                                                                                                                                                                                                1) ТМ оперативно закрыли дыру а не стали рассказывать басни
                                                                                                                                                                                                                2) это ж когда было то? Еще при царе Горохе
                                                                                                                                                                                                                Если бы в NASA писали на фреймворках, то, боюсь, до сих пор ни одного спутника запущено бы не было, всё ждали бы, пока программисты доведут прошивку до production-ready

                                                                                                                                                                                                                А если бы все писали всё самостоятельно, без чужих библиотек, то ваше сообщение я бы читал с перфокарты.
                                                                                                                                                                                                                А вот вылез какой-то страшный баг во фреймворке, и ты сидишь и думаешь — как же теперь эту сборную солянку из непонятных библиотек, полных магии, обновлять?

                                                                                                                                                                                                                Так а что сложного то? Просто берешь и поступаешь как Антонн — говоришь что это не баг а фича, и всё, проблема решена.
                                                                                                                                                                                                                А если серьезно — да, с некоторого уровня квалификации свой код будет не сильно уступать, а местами и выигрывать. Но при этом он будет сильно ограничивать тебя в скорости разработки чего-то более-менее серьезного.
                                                                                                                                                                                                                • 0
                                                                                                                                                                                                                  Так а что сложного то? Просто берешь и поступаешь как Антонн — говоришь что это не баг а фича, и всё, проблема решена.

                                                                                                                                                                                                                  Собственно, очень часто мейнтейнеры всяких модных крупных проектов так и делают. Гляньте сюда, например, тикету уже скоро два года, а воз и ныне там, «это фича, а не баг»: github.com/moby/moby/issues/25526 или сюда: github.com/moby/moby/issues/33402

                                                                                                                                                                                                                  И вот ты вынужден сидеть и строить костыли для обхода таких штуковин. С другой стороны, если бы крепко задумался о необходимых функциях на старте проекта, то можно было всё сделать самому и безо всяких докеров, и совершенно от них и их багов не зависеть, оперативно исправляя проблемные моменты по мере их возникновения.

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

                                                                                                                                                                                                                  1) ТМ оперативно закрыли дыру а не стали рассказывать басни
                                                                                                                                                                                                                  2) это ж когда было то? Еще при царе Горохе
                                                                                                                                                                                                                  Согласитесь, «навесил костыль над протоколом» и «закрыл дыру» — несколько разные вещи.

                                                                                                                                                                                                                  Ну примерно с этого все и началось. Антонн утверждал что у него все чики-пуки и без фреймворков, и без нормальной квалификации, я говорил что лишь постольку поскольку никто его и не ломает.
                                                                                                                                                                                                                  Вообще, использование фреймворка никак не предотвратит неуловимого Джо в суперкрутого разработчика.
                                                                                                                                                                                                                  • +2
                                                                                                                                                                                                                    Вообще, использование фреймворка никак не предотвратит неуловимого Джо в суперкрутого разработчика.

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

                                                                                                                                                                                                                  Это как-то влияет на преимущества использования фреймворков или на необходимость защиты от уязвимостей?
                                                                                                                                                                                                                  Это как-то доказывает необходимость использования своей системы шифрования вместо OpenSSL?
                                                                                                                                                                                                                  А кто говорит о том, что он прекрасен? И как из этого следует, что в своем коде будет лучше архитектура или меньше ошибок?
                                                                                                                                                                                                                  А кто говорит о моде?


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

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


                                                                                                                                                                                                                  Свой код можно обновлять по мере необходимости и атомарно.

                                                                                                                                                                                                                  Представьте себе, сторонний тоже.


                                                                                                                                                                                                                  как же теперь эту сборную солянку из непонятных библиотек, полных магии, обновлять? — ибо всё начинает рассыпаться

                                                                                                                                                                                                                  Для того, чтобы так не было, используется семантическое версионирование. Например, изменение последней цифры означает, что изменения не ломают обратную совместимость.
                                                                                                                                                                                                                  А вот как обновлять свой движок, скопированный на 20 сайтов в разных версиях, это непонятно.

                                                                                                                                                                                                                  • 0
                                                                                                                                                                                                                    Это как-то влияет на преимущества использования фреймворков или на необходимость защиты от уязвимостей?

                                                                                                                                                                                                                    В том-то и дело, что никак абсолютно. Наплевать на фреймворки, от них ничего не зависит.

                                                                                                                                                                                                                    И как из этого следует, что в своем коде будет лучше архитектура или меньше ошибок?

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

                                                                                                                                                                                                                    Эм, обсуждаемый сайт критическое приложение?

                                                                                                                                                                                                                    Ну и что ж вы тогда так паритесь по поводу его уязвимости?

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

                                                                                                                                                                                                                    Ага, в идеальном мире, где по цветочным полянкам бегают розовые пони, может быть, все и следуют семверу, и там никогда ничего не ломается из-за обновления зависимостей. Но мир реальный совершенно не таков.
                                                                                                                                                                                                                    • 0
                                                                                                                                                                                                                      Потому что свой код лучше изучен и понятнее его автору. Да, это может создать излишние издержки для бизнеса, но и добавит безопасности и маневренности.

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

                                                                                                                                                                                                                      • 0
                                                                                                                                                                                                                        Ну Вы же понимаете, что это уже не из области плюсов-минусов фреймворка, тут всё начинает зависеть от организации рабочих процессов. С фреймворком тоже можно написать дырявую лажу и забить на аудит.
                                                                                                                                                                                                                        • +1
                                                                                                                                                                                                                          У фреймворка основной набор уязвимостей закрыт из коробки. Если бы антонн писал свой сайт под фреймворком, то даже с его уровнем квалификации сайт был бы относительно защищенным.