fix(auth): ротация API-токена против token fixation

[Ibochkarev]

Описание

На login / register (auto-login) / email verify / checkout auto-login больше не делается rebind guest API-токена к аккаунту. Выдаётся новый токен, guest draft мигрирует при безопасном владельце, старый guest/own токен отзывается, вызывается session_regenerate_id(true).

Закрывает классический token fixation: planted ms3_token=T после входа жертвы больше не даёт доступ по тому же T.

Тип изменений

• Исправление бага (non-breaking change)
• Новая функциональность (non-breaking change)
• Breaking change (изменение, ломающее обратную совместимость)
• Рефакторинг (без изменения функциональности)
• Документация
• Другое (опишите):

Связанные Issues

Closes #412

Смежно с #369 (checkout email capture) — здесь ещё и Customer::autoLoginCustomer переведён на тот же establishApiSession.

Как это было протестировано?

cd core/components/minishop3
php -l src/Services/Customer/AuthManager.php
php tests/ApiTokenRotationPolicyTest.php   # exit 0
composer ci:php                           # exit 0

Gate E (эта сессия):

• php -l touched PHP — OK

• php tests/ApiTokenRotationPolicyTest.php — OK (policy + regression guards)

• composer ci:php — OK (exit 0)

• Vue — n/a

• Ручное тестирование

• Автоматические тесты (composer ci:php)

• Тестирование на разных версиях PHP/MODX

Конфигурация тестирования:

• MiniShop3: ветка fix/issue-412-token-fixation-rotation
• MODX: n/a (smoke без MODX)
• PHP: 8.2+

Скриншоты (если применимо)

n/a

Чеклист

• Код соответствует стилю проекта
• Добавлены/обновлены комментарии в сложных местах
• Изменения не ломают существующую функциональность
• Лексиконы добавлены на двух языках (ru/en) — не требуются
• PHPStan проходит без новых ошибок (локально; в CI пока нет)
• ESLint — n/a
• CHANGELOG.md — на релизе

Дополнительные заметки

Поведение для клиентов: после login/register/verify в ответе/cookie приходит новый token (значение меняется). Guest-корзина сохраняется через migrate draft.

Отложено (не блокер): Register при редком fail createToken после уже созданного customer отдаёт failure (повтор → email занят). Follow-up UX.

Review: code-reviewer, thermo-nuclear, security-review, silent-failure-hunter; 1 fix-loop (checkout autoLogin + migrate hardening + HTML verify).

[biz87]

Закрываю как субсумированный #321 (влит в beta, 6e15bf6).

AuthManager::establishApiSession() из этого PR делает ровно то же, что теперь делает AuthManager::establishCustomerSession() в beta:

• всегда mint нового API-токена на login/register/verify (guest-токен не апгрейдится → token fixation закрыт);
• перенос гостевой корзины на новый токен при безопасном владельце — предикат canTransferCartFromToken(prevOwnerId, customerId) в fix(customer): restore storefront login and session auth #321 эквивалентен здешнему canMigratePreviousApiToken (guest/own → перенос+revoke; foreign → не трогаем);
• отзыв старого токена;
• session_regenerate_id(true).

Регресс-покрытие ротации уже в beta (session-семантика — CustomerAuthSessionSemanticsTest; anti-fixation — через establishCustomerSession). Отдельная реализация establishApiSession больше не нужна.

Если в #321-версии найдётся пробел относительно этого PR — переоткроем точечно. Спасибо!