Android-приложение не возвращает сессионные куки в MFP 7.1

Question

1) Тип приложений: Мобильный банкинг
2) Существующая версия Worklight: 6.1 (потребительская версия)
3) Cordova Версия: 3.1.0
4) Поддерживаемая платформа: Android 4.2+, iOS 7+
5) ОС сервера: Windows Server 2008
6) Сервер приложений: Профиль IBM WebSphere Liberty
7) База данных: IBM DB2

Приложения были реализованы с помощью обработчика Custom Challenge для аутентификации пользователя из IBM WebSeal, ChallengeHandler отправляет HTTPS-запросы в IBM WebSeal для выполнения следующих действий:

1. Получите параметры входа из IBM WebSeal (например, тип страницы входа, URL для отправки формы входа)
2. Обмен ключами шифрования (поверх HTTPS Банк требует дальнейшего шифрования трафика с помощью jCryption)
3. Отправить зашифрованное имя пользователя / пароль

Все вышеперечисленные шаги были реализованы с помощью функции jjuery ajax(), post() или getJson(), она отлично работает в приведенной выше настройке.

Проблемы
После обновления Worklight 6.1 до MobileFirst 7.1, вышеупомянутый метод аутентификации больше не работает на устройствах Android, с другой стороны, iOS все еще работает как задумано.

Потратив несколько дней на поиск и устранение неисправностей в подробных журналах запросов и ответов, мы пришли к выводу, что Android имеет другой контекст управления файлами cookie между jQuery ajax() post() и HTTP-запросами MobileFirst.

Пример:
Используя WLJQ.ajax(… myUrl …) для генерации ответа Set-Cookie, Cookie будет автоматически добавляться ко всем запросам ajax подпоследовательности, когда запрос находится в соответствующем домене.

Но заголовок ответа Set-Cookies из запроса ajax () не влияет на следующие функции HTTP-запроса MobileFirst: 1. ChallengeHandler.submitLoginForm
2. WL.Client.invokeProcedure
3. WL.Client.login

Наш ChallengeHandler аутентифицирует пользователя и запоминает пользователя, используя значение cookie, но поскольку файлы cookie не будут совместно использоваться MobileFirst и jQuery, поэтому вызов WL.Client.InvokeProcedure будет заблокирован IBM WebSeal, поскольку запрос был идентифицирован как не прошедший проверку подлинности пользователь.

Мы также заметили, что пользовательский агент для jQuery ajax/post очень отличается от вышеуказанных функций MobileFirst:

Пользовательский агент MobileFirst: Dalvik/2.1.0 (Linux; U; Android 6.0.1; SM-G925F Build/MMB29K)/Worklight/7.1.0.0 WLNativeAPI(нулевая; MMB29K.G925FXXU3DPCN; SM-G925F; SDK 23; Android 6.0 0,1)

jQuery (работает на Samsung Galaxy S6)
User-Agent: Mozilla / 5.0 (Linux; Android 6.0.1; SM-G925F Build / MMB29K; wv) AppleWebKit / 537.36 (KHTML, как Gecko) Версия /4.0 Chrome/49.0.2623.105 Mobile Safari/537.36/Worklight/7.1.0.0

Сводка неполадок
1) Обновите CookieManager для Android, чтобы принимать сторонние куки

CookieManager cookieManager = CookieManager.getInstance (); cookieManager.setAcceptThirdPartyCookies (webView, true);

2) Вручную получить значения cookie из jQuery post() и добавить в функцию MobileFirst, используя WL.Client.setCookie.

Но из-за ограничений браузера мы не смогли получить значение заголовков Set-Cookie

3) Преобразуйте все вызовы jQuery, чтобы использовать challengeHandler.submitLoginForm, но при таком подходе сеанс MobileFirst сбрасывается после каждого вызова вышеуказанного кода, поэтому он все еще не работает.

Answer 1

После открытия PMR в IBM это действительно изменение дизайна, начиная с WL 6.2. Согласно IBM ниже:

• В операционной системе iOS Cookie Storage управляется одноэлементным объектом (общим экземпляром). В результате куки-файлы приложения распределяются между AJAX-запросами из Webview и из собственных запросов. Это причина того, почему перенесенное приложение iOS с версии 6.1 на версию 6.1 продолжает работать без изменения кода

• В операционной системе Android это не так. Хранение файлов cookie специфично для каждого http-клиента, поэтому AJAX и собственные запросы не разделяют файлы cookie. Изменение кода приложения требуется в случае, если приложение выпускает пользовательские запросы AJAX

Мы изменили наш код, чтобы использовать рекомендованный IBM API WLResourceRequest.

Answer 2

Будет лучше, если вы сформулируете свой текст как вопрос. Не ясно, если у вас есть вопрос.

Если вы это сделаете, то тема, представленная в вопросе, требует открытия IBM PMR (тикета поддержки), так как не удастся обработать его с помощью вопроса в Stackru.

Если вы открываете PMR, пожалуйста, предоставьте полное воспроизведение.