Наглядный пример того, что будет, если мы не будем проверять данные, которые пришли от пользователя на примере Laravel.
Рейтинг
( 2 оценки, среднее 3 из 5 )
Максим Гречушников/ автор статьи
Мне 40 лет, и больше половины жизни я занимаюсь разработкой. За это время я работал с корпоративными системами, highload-проектами, интеграциями, платежными решениями, внутренними платформами и legacy-кодом, который пережил не одного разработчика. Некоторые системы, кажется, переживут и нас.
Моя специализация — PHP, Laravel, backend-архитектура, DDD, тестирование, рефакторинг и техническое лидерство. Мне интересны задачи, где нужно соединить код, бизнес, данные, процессы и здравый смысл.
Последние годы я много работаю с LLM и AI-инструментами: использую их для проектирования, анализа кода, документации, тестов, ревью, работы с legacy и построения инженерных процессов. Для меня LLM — это не замена разработчику, а усилитель для тех, кто умеет думать системно.
В блоге я пишу о Laravel, PHP, архитектуре, тестировании, инженерной практике, управлении разработкой и реальном применении AI в работе программиста.
Понравилась статья? Поделиться с друзьями:
Вам также может быть интересно
Centrifugo — сильное решение для real-time систем. Особенно когда нужен отдельный WebSocket-слой, приватные каналы,
Real-time система не заканчивается на том, что backend опубликовал событие в Centrifugo. Это только
Real-time в Laravel-проекте не должен начинаться с прямого HTTP-запроса к Centrifugo из контроллера. Это
В предыдущей статье мы разобрали архитектуру Laravel + Centrifugo: Laravel отвечает за бизнес-логику, права
В первой части мы разобрались, что Real-time на Laravel-сайте нужен там, где интерфейс должен
Большинство web-приложений исторически строится вокруг простой и надёжной модели: пользователь отправляет запрос, сервер его