Политика IGNORE_COOKIES адаптера MobileFirst 6.3 по-прежнему отправляет файлы cookie

Мы используем настраиваемую подготовку устройств для аутентификации устройств в нашем серверном модуле WebSphere Portal.

Наш адаптер настроен на подключение в качестве конечного пользователя, а политика файлов cookie — на IGNORE_COOKIES.

Но по какой-то причине адаптер по-прежнему использует общий токен Ltpa для подключения к серверной части для всех устройств.

В этом состоянии пользователь еще НЕ аутентифицирован на сервере Worklight, поэтому я не уверен, будет ли параметр подключения от имени конечного пользователя работать должным образом. А IGNORE_COOKIES должен?

var input = {
    method : 'get',
    returnedContentType : 'json',
    path : 'DeviceService/DeviceInfo/' + deviceId,
    headers : {"Authorization": "Basic " + auth},
    parameters : {
        token: token
    }
};

try {
    var result = WL.Server.invokeHttp(input);
    return result;
} catch (e) {
    WL.Logger.error("ERROR: " + e);
    return null;
}

Наш файл authenticationConfig.xml выглядит следующим образом:

<?xml version="1.0" encoding="UTF-8"?><tns:loginConfiguration xmlns:tns="http://www.worklight.com/auth/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <!-- Licensed Materials - Property of IBM
             5725-I43 (C) Copyright IBM Corp. 2006, 2013. All Rights Reserved.
             US Government Users Restricted Rights - Use, duplication or
             disclosure restricted by GSA ADP Schedule Contract with IBM Corp. -->
    <securityTests>
        <mobileSecurityTest name="MAPCertLogin">
            <testDeviceId provisioningType="custom" realm="MAPLoginRealm"/>
            <testAppAuthenticity/>
        </mobileSecurityTest>
    </securityTests>
    <realms>
        <realm loginModule="StrongDummy" name="SampleAppRealm">
            <className>com.worklight.core.auth.ext.FormBasedAuthenticator</className>
        </realm>
        <realm loginModule="MAPLoginModule" name="MAPLoginRealm">
            <className>com.worklight.core.auth.ext.DeviceAutoProvisioningAuthenticator</className>
            <parameter name="validate-csr-function" value="Authenticator.validateCSR"/>
        </realm>
    </realms>
    <loginModules>
        <loginModule name="StrongDummy">
            <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className>
        </loginModule>
        <loginModule name="requireLogin">
            <className>com.worklight.core.auth.ext.SingleIdentityLoginModule</className>
        </loginModule>
        <loginModule name="MAPLoginModule">
            <className>com.worklight.core.auth.ext.DeviceAutoProvisioningLoginModule</className>
            <parameter name="validate-certificate-function" value="Authenticator.validateCertificate"/>
        </loginModule>
    </loginModules>
</tns:loginConfiguration>

Я больше не могу это подтвердить, но я уверен, что это работало в нашей среде Worklight 6.2.

Что может быть причиной того, что токен ltpa все еще отправляется?


person Stijn    schedule 18.03.2015    source источник
comment
Stijn, можете ли вы добавить к вопросу ваш файл authenticationConfig.xml?   -  person Idan Adar    schedule 18.03.2015
comment
Спасибо, Идан Адар, я добавил XML к вопросу.   -  person Stijn    schedule 19.03.2015
comment
Привет, Идан Адар, тебе удалось воспроизвести проблему? Я создал тестовое приложение без каких-либо тестов безопасности, и в этой ситуации все работает как надо, но как только я добавил код подготовки, сервер начинает использовать общий токен ltap. Любая идея, с чего начать, чтобы решить эту проблему?   -  person Stijn    schedule 20.03.2015


Ответы (2)


Для этой проблемы обнаружен дефект, и для клиентов IBM доступно исправление. Обратитесь в службу поддержки IBM за дополнительными сведениями.

ibm.com/support

person Leandro David    schedule 05.05.2015

ИМХО: политику куки трогать не стоит. Политика использования файлов cookie в основном предназначена для правильного анализа файлов cookie с Worklight на внутренний HTTP-сервер и наоборот. В качестве побочного эффекта файл cookie может быть передан обратно клиенту. Это правда, что Liberty прикрепит к входящему HTTP-запросу токен LTPA, но это не должно беспокоить ваше приложение. Он просто добавляется в файл cookie ответа. Единственный случай, когда сервер Worklight начнет проверять этот файл cookie, — это использование модуля WorklightLTPAAuthenticator. Я не видел, чтобы ты его использовал. Вы используете подготовку устройства, которая опирается на правильные заголовки WWW-authenticate и некоторые ответы JSON. Если у вас возникла ошибка при подготовке устройства, вам следует проверить обработчик вызовов в клиенте, который обрабатывает рукопожатие CSR.

person taitelman    schedule 19.04.2015
comment
Спасибо, Taitelman, за ответ. Но проблема не в соединении между клиентом и сервером Worklight. Обработчик вызовов работает по назначению. Сервер Worklight отправляет для каждого устройства один и тот же токен ltpa на серверную часть. Это заставляет внутренний сервер идентифицировать каждое устройство как одного и того же пользователя. Поэтому отображаемый контент неверен. - person Stijn; 20.04.2015
comment
На 2-й мысли вы, возможно, правы. Я проверяю код, чтобы понять проблему. сервер не игнорирует cookie, как ожидалось. это, вероятно, влияет на уровень Worklight v6.3 +ifix от 28 декабря 2014 г. или более поздней версии, а также v7.0. - person taitelman; 21.04.2015