Sylius API: конфликт тележек при входе в систему - PullRequest
Новая
       8

Sylius API: конфликт тележек при входе в систему

0 голосов
/ 06 июля 2018

Я использую 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 Ответ

0 голосов
/ 10 июля 2018

Хорошо, разобрался, что происходит. 2 вещи:

1 / При интерактивном / неявном входе в систему Sylius пытается получить существующую корзину (если пользователь добавил элементы в корзину до входа в систему, режим внешнего интерфейса). Для этого Sylius использует нечто, называемое cartContext, с несколькими различными контекстами. Первая попытка получить корзину на основе канала (название магазина) и покупателя (текущий вошедший в систему пользователь). Если корзина не возвращается (в моем случае), она использует другой контекст, который пытается получить корзину на основе канала (все тот же) и сеанса. И здесь он выбрал не ту корзину, и это затронуло моего нового пользователя. Так что теперь у меня есть корзина, которая изначально не моя.

2 / Я знаю, что из-за сессии получилась неправильная корзина. Но я нахожусь в режиме без гражданства, поэтому ничего не должно быть возвращено, и Силиус должен был создать новый для меня, но это не так. Сессия существует для моего нового пользователя и выглядит так же, как последний пользователь. Кажется, что Symfony запускает сеанс, если в конфигурации брандмауэра установлен режим авторизации form_login, независимо от того, что вы делаете, он запускает сеанс.

Итак, что мы имеем: Sylius получает неправильную корзину из-за контекста сеанса. Symfony действительно начинает сеанс по API входа. Но так как я использую реагировать как родной в качестве внешнего интерфейса, и он не работает в веб-представлении, сессия не должна быть одинаковой (я не передаю какой-либо файл cookie или что-то в этом роде, просто выполняю аутентификацию с помощью веб-токена json, и он отличается для моих двух различий пользователи). Даже если с аутентификацией все в порядке, мой пользователь правильно вошел в систему с исправлениями личной информации, они совместно используют один и тот же сеанс бэкэнда. И это где я не понимаю, почему. Единственная подсказка, которую я имею, я из-за реагирующего нативного режима отладки javscript симулятора, который может использовать прокси и посылать сессионный cookie. Я абсолютно не уверен в этом, но почему бы и нет :)

Итак, теперь обходной путь, и он очень уродливый / хакерский: я просто установил глобальный прослушиватель запросов, который прослушивает только запросы не html, и лишил законной силы сеанс ..

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

...