Игнорируется Accept-Language при получении access токена с помощью refresh токена через REST API

Вопросы и проблемы
#1

Здравствуйте!

Моё приложение использует Cuba Platform версии 6.10.9 и REST API для взаимодействия с клиентом. Некоторые его функции связаны с языком локализации, который используется клиентом. Для того, что бы определить язык, при получении access токена устанавливается заголовок Accept-Language (например, со значением ru). После этого в обработчиках запросов указанный язык можно получить, вызвав метод

UserSessionSource.getLocale().getLanguage()

И в этом случае метод возвращает корректное значение, указанное клиентом при получении токена.
Далее, после истечения времени жизни access токена (или просто для обновления), делается запрос на получение нового с использованием refresh токена. При этом заголовок Accept-Language так же указывается. Но, после этого метод

UserSessionSource.getLocale().getLanguage()

возвращает уже не указанный клиентом язык, а язык системы по умолчанию.
Я создал demo проект для демонстрации проблемы. Он доступен в репозитории https://github.com/ElusiveAvenger/cp-refresh-token-Accept-Language-ignore
В проект добавлен всего один RestController для демонстрации (DemoController) с единственным методом, который возвращает язык сессии. В readme.md в корне репозитория описан подробный сценарий повторения проблемы.
Ровно тоже самое происходит при использовании метода

UserSessionSource.getUserSession().getLocale().getLanguage()

Добавление заголовка Accept-Language с нужным значением языка клиента в запрос, обработчику которого оно необходимо, так же не меняет результат.

Подскажите, пожалуйста, ожидаемо ли такое поведение системы? Если да, то что мне нужно сделать, что бы получить необходимую мне информацию о языке клиента? Если поведение не является ожидаемым, то как в указанной версии платформы я могу обойти описанную проблему (если это вообще возможно)?

1 симпатия
#3

Добрый день!
Спасибо за детальное описание проблемы. Мы завели тикет: https://github.com/cuba-platform/cuba/issues/2045
Чтобы анализировать заголовок ‘Accept-Language’ для конкретных контроллеров и проставлять локаль в сессию, добавьте фильтр cuba_RestLastSecurityFilter в своём rest-dispatcher-spring.xml

    <security:http pattern="/rest/**"
                   create-session="stateless"
                   entry-point-ref="oauthAuthenticationEntryPoint"
                   xmlns="http://www.springframework.org/schema/security">
        <intercept-url pattern="/rest/**" access="true"/>
        <anonymous enabled="true"/>
        <csrf disabled="true"/>
        <cors configuration-source-ref="cuba_RestCorsSource"/>
        <custom-filter ref="resourceFilter" before="PRE_AUTH_FILTER"/>
        <custom-filter ref="cuba_AnonymousAuthenticationFilter" after="PRE_AUTH_FILTER"/>
        <custom-filter ref="cuba_RestLastSecurityFilter" after="LAST"/>
    </security:http>
2 симпатии
#5

Здравствуйте, подскажите пожалуйста, можно ли добавить этот фильтр не только для конкретных контроллеров, но и для дефолтного api платформы (/rest/v2/**)? На данный момент, предложенный вами вариант работает только для кастомного api.

#6

Добрый день. Для стандартного API он должен быть объявлен. Что именно не работает? На какой версии платформы и как можно воспроизвести проблему?

#7

Версия платформы 6.10.4. Не обрабатывается заголовок Accept-Language при выполнении запросов по типу “http://localhost:8080/app/rest/v2/entities/sales$Order” (язык сессии остаётся прежним, вне зависимости от переданного заголовка). Сейчас дополню demo-проект.

Демо-проект с добавленным фильтром и сервисом, возвращающим текущий язык сессии:

#8

Summon @gorbunkov :slight_smile:

#9

Да, это не работает для сервисов. Создали тикет: https://github.com/cuba-platform/cuba/issues/2067
Для запросов, например, получения списка локализованных сообщений http://localhost:8080/app/rest/v2/messages/entities/sec$User заголовок отрабатывает нормально.

#10

@gorbunkov, А если запрашивать не сообщения, а именно сущности, то заголовок снова не обрабатывается. Вам нужно снова дополнить demo, или вы сами проверите?

#11

Посмотрим сами. Причина там, я думаю, та же самая

#12

@gorbunkov, Большое спасибо! Будем ждать фикса! :slight_smile: