💡 Symfony 8.2 сможет делать подписанную ссылку недействительной после смены пароля

Подпись защищает URL от подмены. Но сама по себе не мешает открыть одну ссылку несколько раз до истечения срока.

В разрабатываемом Symfony 8.2 у UriSigner появляется дополнительный аргумент $version. Он участвует в подписи, но не добавляется в URL.

Для сброса пароля версией может стать текущий хеш пароля:

$url = $uriSigner->sign(
    $resetUrl,
    new \DateInterval('PT30M'),
    $user->getPassword(),
);

// При обработке ссылки:
$uriSigner->verify($request, $user->getPassword());

После сохранения нового пароля хеш изменится. Проверка старой ссылки с новым значением версии завершится исключением UnverifiedSignedUriException.

Важная деталь: verify() не погашает ссылку

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

Возможность относится к будущему Symfony 8.2. Для текущего проекта сначала проверьте версию компонента.

🔗 Как работает версия подписанной ссылки

🐸 Библиотека пхпшника

😎 Выбираешь один курс, второй получаешь бесплатно. Баг? Нет, акция!

До 31 октября в Proglib Academy можно выбрать два курса и заплатить только за один.

Например, можно совместить:

💥 ИИ для разработчиков — применение нейросетей в повседневной разработке: работа с кодом, тестирование и ревью.

💥 Разработка ИИ-агентов — архитектура агентов и создание собственных AI-решений.

Вместе курсы стоят 108 000 ₽, но по акции оба обойдутся в 59 000 ₽. Экономия — 49 000 ₽ 🔥

Интересуют Python и ИИ или алгоритмы и архитектура? Можно выбрать любые два курса из каталога.

Акция действует до 31 октября включительно ⏳

⏬ Собрать свой учебный билд

🛠 Миграция Pinkary на MySQL обнаружила UUID в целочисленных столбцах

Приложение работает, тесты зелёные — пока не меняется движок базы данных.

В Pinkary первичный ключ questions.id был UUID. А поля parent_id и root_id создали через foreignId(), то есть как целочисленные столбцы:

$table->foreignId('parent_id');

Гибкая типизация SQLite позволяла хранить там строки UUID. При переходе на MySQL несоответствие стало проблемой: тип столбца должен соответствовать реальным значениям и связанному ключу.

Здесь легко сделать слишком широкий вывод. Проблема была именно в явных вызовах foreignId('parent_id') и foreignId('root_id'). Метод foreignIdFor() умеет определять UUID-тип по модели — это другой случай.

Что проверить до переезда

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

ORM делает запросы удобнее, но не делает SQLite и MySQL взаимозаменяемыми во всех деталях.

🔗 Разбор миграции от разработчика Pinkary

🐸 Библиотека пхпшника

💡 EntityExists в Symfony 8.2 проверит сущность по идентификатору, но пропустит пустое значение

API получает userId. Проверить, что это строка, недостаточно: пользователь с таким идентификатором может не существовать.

В будущем Symfony 8.2 для этой задачи появится ограничение EntityExists из Doctrine Bridge:

use App\Entity\User;
use Symfony\Bridge\Doctrine\Validator\Constraints\EntityExists;
use Symfony\Component\Validator\Constraints as Assert;

final class AssignOrderCommand
{
    #[Assert\NotBlank]
    #[EntityExists(entityClass: User::class)]
    public string $userId;
}

По умолчанию поиск идёт по идентификатору сущности. Можно выбрать другое поле через identifierField или задать собственный метод репозитория.

Зачем рядом NotBlank

EntityExists считает null и пустую строку допустимыми. Если поле обязательно, это отдельное правило.

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

Поэтому авторизацию и ограничения целостности базы такая валидация не заменяет.

🔗 Новые ограничения валидации Symfony 8.2

🐸 Библиотека пхпшника

🛠 Laravel Cloud создаёт отдельное окружение для проверки каждого pull request

Один staging на всю команду быстро превращается в очередь: пока дизайнер смотрит одну ветку, следующую выкатывать нельзя.

В Laravel Cloud можно настроить автоматизацию, которая создаёт окружение при открытии pull request. У него будут собственный URL и отдельно созданные ресурсы. Новые коммиты обновляют развёрнутую версию, а после закрытия или слияния PR автоматическая очистка может удалить окружение и созданные для него ресурсы.

Это возможность платформы Laravel Cloud, а не функция, которая автоматически появляется в любом Laravel-приложении.

Изоляция важнее дополнительного URL

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

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

Полезный результат — возможность проверить весь пользовательский сценарий, не перезаписывая чужой staging.

🔗 Как устроены окружения для pull request

🐸 Библиотека пхпшника

📌 Один курс — хорошее вложение в себя. Два по той же цене — ещё лучше.

В Proglib Academy действует акция: покупаешь один курс, а второй получаешь в подарок.

Например, можно совместить два направления по работе с ИИ:

💥 ИИ для разработчиков — применение нейросетей в повседневной разработке: работа с кодом, тестирование и ревью.

💥 Разработка ИИ-агентов — архитектура агентов и создание собственных AI-решений.

📍 Разница в цене — почти 50 тысяч рублей. Можно освоить больше, не выходя за рамки запланированного бюджета.

А если тебе интереснее Python, алгоритмы, backend или DevOps — выбирай другую пару курсов из каталога.

Акция действует до 31 октября включительно ⏳

⏮️ Пора прокачать свой стек

⚡️ Symfony 8.2 заранее подготовит список слушателей вместо повторной регистрации на каждом запросе

Контейнер уже знает, какие слушатели обрабатывают события. Зачем при создании диспетчера снова вызывать addListener() и создавать замыкания?

В разрабатываемом Symfony 8.2 сервис event_dispatcher использует CompiledEventDispatcher. Он получает заранее подготовленный массив идентификаторов сервисов и методов в нужном порядке. OPcache хранит массив в общей памяти, а локатор загружает слушателей по мере необходимости.

В приведённом микробенчмарке с 75 слушателями создание диспетчера сократилось с 33,7 до 0,48 микросекунды.

Это ускорение создания, а не всего приложения

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

Добавление и удаление слушателей на общем event_dispatcher во время выполнения заставляет его перейти к обычному диспетчеру. В Symfony 8.2 такие вызовы помечаются устаревающими.

Перед обновлением стоит поискать addListener(), addSubscriber() и соответствующие удаления именно на общем сервисе.

🔗 Как работает скомпилированный диспетчер

🐸 Библиотека пхпшника

💡 Laravel MCP 1.0 ищет нужные инструменты в каталоге вместо передачи всех схем сразу

У MCP-сервера десятки инструментов. Если клиент заранее добавляет каждое описание и полную схему параметров в контекст модели, значительная его часть расходуется ещё до первого полезного вызова.

В Laravel MCP 1.0 разработчики выбрали каталог с поиском: агент сначала находит подходящий инструмент, затем получает необходимую информацию для вызова. Размер начального tools/list при этом не растёт вместе со всем каталогом.

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

Почему от eval() отказались

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

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

Это разбор конкретной реализации. Не каждый MCP-клиент заранее загружает все схемы, а поиск инструмента не заменяет проверку прав при его выполнении.

🔗 История четырёх вариантов Laravel MCP

🐸 Библиотека пхпшника

🛠 После исправления критических уязвимостей PHP проверьте способ обновления приложения

21 октября вышли исправления двух критических уязвимостей PHP, допускающих удалённое выполнение кода без авторизации. Обновлённые версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35.

В инструкции для платформ Laravel разобраны действия для каждого способа размещения. На Laravel Cloud работающие приложения обновили автоматически. На Forge нужно нажать Update PHP для каждого сервера. На Vapor приложения с нативным runtime PHP 8.2 и новее требуется развернуть повторно; для собственного Docker-образа подготовить новое развёртывание.

Проверьте все окружения и процессы приложения: веб-сервер, очереди и задания по расписанию. Для контейнеров пересоберите образ с исправленной версией PHP и замените работающие экземпляры.

➡️ Навигация: База знаний • Задачи • Собеседования • Вакансии

🐸 Библиотека программиста

💡 Symfony 8.2 сможет блокировать параллельные вызовы контроллера

Два запроса одновременно запускают импорт каталога. Оба обработчика читают и изменяют одни данные. В готовящемся Symfony 8.2 для таких операций появится атрибут #[Lock]:

use Symfony\Component\HttpKernel\Attribute\Lock;

#[Lock('catalog-import', methods: 'POST')]
public function import(): Response
{
    // Импорт каталога
}

Первый запрос получает блокировку. Конкурирующий запрос с тем же ключом по умолчанию получает 409 Conflict. Режим blocking: true позволяет дождаться освобождения блокировки.

Это пригодится для импорта, генерации отчётов и других операций с общим ресурсом. Подберите ключ под этот ресурс и проверьте длительность обработки: стандартный TTL — 30 секунд. Для долгой работы блокировку нужно продлевать. При нескольких экземплярах приложения настройте общее хранилище блокировок.

➡️ Навигация: База знаний • Задачи • Собеседования • Вакансии

🐸 Библиотека программиста