Sylius API: конфликт тележек при входе в систему
Я использую Sylius (Symfony SyliusBundle) в качестве серверной части с мобильным приложением, и у меня возникла проблема с конфликтом тележек. Я использую токен lexikJWT с sylius_shop_provider по умолчанию для аутентификации моих пользователей. Аутентификация работает нормально, я могу войти в систему и получить все данные моего пользователя. Вот в чем проблема:
После аутентификации я создаю корзину, добавляю в нее товары, все работает нормально. Теперь я выхожу из системы, создаю нового пользователя, и когда я вхожу в систему с новым созданным пользователем, я получаю корзину моего предыдущего пользователя!
Я использую $this->get('sylius.context.cart')->getCart(); по умолчанию для создания или получения корзины, но customer_id заказа изменился после входа в систему.
Понятия не имею, почему, ни документа, ничего. Я только что проверил код sylius, и что-то должно быть связано с этим:
Существует слушатель под названием CartBlamerListener, который переопределяет клиента корзины, если он существует:
private function blame(ShopUserInterface $user)
{
$cart = $this->getCart();
if (null === $cart) {
return;
}
$cart->setCustomer($user->getCustomer());
$this->cartManager->persist($cart);
$this->cartManager->flush();
}
Кажется, что он находит уже существующую корзину (тележку моего предыдущего пользователя) и заменяет поле клиента полем нового пользователя, но этого не должно быть !!!
Есть идеи, что происходит?
Ниже мой файл безопасности:
api_login:
pattern: ^/api/login
stateless: true
anonymous: true
form_login:
provider: sylius_shop_user_provider
check_path: /api/login_check
success_handler: lexik_jwt_authentication.handler.authentication_success
failure_handler: lexik_jwt_authentication.handler.authentication_failure
require_previous_session: false
api:
pattern: ^/api
anonymous: true
stateless: true
provider: sylius_shop_user_provider
guard:
authenticators:
- lexik_jwt_authentication.jwt_token_authenticator
Ответы 1
Хорошо разобрался в чем дело. 2 вещи:
1 / При интерактивном / неявном входе в систему Sylius пытается получить существующую корзину (если пользователь добавил элементы в корзину до входа в систему, режим внешнего интерфейса). Для этого Силиус использует нечто, называемое «cartContext», с несколькими разными контекстами. Первый пытается получить корзину на основе канала (название магазина) и покупателя (текущего пользователя, вошедшего в систему). Если корзина не возвращается (мой случай), он использует другой контекст, который пытается получить корзину на основе канала (все тот же) и сеанса. И именно здесь он выбрал не ту корзину и повлиял на нее для моего нового пользователя. Итак, теперь у меня есть тележка, которая изначально не моя.
2 / Я знаю, что он получил неправильную корзину из-за сеанса. Но я нахожусь в режиме без сохранения состояния, поэтому ничего не нужно возвращать, и Силиус должен был создать для меня новый, но этого не происходит. Для моего нового пользователя существует сеанс, который выглядит таким же, как и последний пользователь. Кажется, что Symfony запускает сеанс, если в конфигурации брандмауэра установлен режим авторизации form_login, независимо от того, что вы делаете, он запускает сеанс.
Итак, что мы имеем: Sylius получает неправильную корзину из-за контекста сеанса. Symfony действительно запускает сеанс при входе в систему через api. Но поскольку я использую response native в качестве внешнего интерфейса, и он не работает в веб-просмотре, сеанс не должен быть таким же (я не передаю никаких файлов cookie или около того, просто авторизуйтесь через веб-токен json, и он отличается для моих двух разных Пользователи) .Даже если авторизация в порядке, мой пользователь правильно вошел в систему с исправленной личной информацией, они используют один и тот же бэкэнд-сеанс. И именно здесь я не понимаю почему. Единственный ключ, который у меня есть, я из-за режима отладки javscript встроенного симулятора реакции, который может использовать прокси и отправлять cookie сеанса. Я в этом абсолютно не уверен, но почему бы и нет :)
Итак, теперь обходной путь, и он очень уродливый / хакерский: я просто установил глобальный прослушиватель запросов, который прослушивает только запросы, отличные от HTML, и аннулирую сеанс.
Надеюсь, это может помочь кому-то другому, я потратил на это слишком много дней.