2

У меня есть приложение Worklight v6.0, использующее аутентификацию на основе адаптера.IBM Worklight 6.0 - Адаптер с базовым auth не обновляет заголовок auth, если клиент выходит из системы/в

Адаптер - это адаптер HTTP, который вызывает базовую услугу REST с использованием Basic Auth.

Сессия или файлы cookie между адаптером и базовым сервисом отсутствуют. В моем дескрипторе адаптера я установил cookiePolicy в IGNORE_COOKIES. Каждый запрос от адаптера к серверу аутентифицируется с помощью основного заголовка auth по этому запросу.

В каждой из процедур адаптера установлено соединение: endUser.

<?xml version="1.0" encoding="UTF-8"?> 
<wl:adapter name="MyAdapter" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:wl="http://www.worklight.com/integration" xmlns:http="http://www.worklight.com/integration/http"> 

<displayName>MyAdapter</displayName> 
<description>MyAdapter</description> 
<connectivity> 
    <connectionPolicy xsi:type="http:HTTPConnectionPolicyType" cookiePolicy="IGNORE_COOKIES"> 
     <protocol>http</protocol> 
     <domain>localhost</domain> 
     <port>9080</port> 
     <!-- Following properties used by adapter's key manager for choosing    
     <authentication> 
      <basic /> 
     </authentication> 
    </connectionPolicy> 
    <loadConstraints maxConcurrentConnectionsPerNode="2" /> 
</connectivity> 

<procedure name="submitAuthentication"></procedure> 

<procedure connectAs="endUser" name="getCurrentUser" 
    securityTest="MyAdapter-securityTest" /> 
</wl:adapter> 

Все это прекрасно работает. Мобильное приложение вызывает защищенную процедуру на адаптере, это инициирует аутентификацию, аутентификация завершается успешно, процедура перезапускается, и я вижу на трассировке сети, что правильный основной заголовок auth накладывается на вызов от адаптера до бэкэнд. Если мобильное приложение совершает вызов адаптера, когда оно уже завершено, адаптер просто делает вызов на обратную связь en с правильным заголовком Basic Auth. Если несколько мобильных приложений подключены одновременно и вошли в систему как разные пользователи, адаптер использует правильный заголовок Basic Auth для вызывающего пользователя.

Единственное, что не работает, - это когда вызов мобильного приложения к адаптеру, аутентифицируется как user1, получает правильный результат от бэкэнда для пользователя1, вызывает WL.Client.logout(), вызывает другой вызов адаптер и аутентифицируется как пользователь 2 на этот раз.

В процедуре адаптера я вызываю WL.Server.getActiveUser() для проверки активного пользователя, и, конечно же, пользователь прав (user2). Но когда вызов выходит на бэкэнд, основной заголовок Auth, который добавляет Worklight, имеет учетные данные для user1, и поэтому мобильное приложение получает неправильные результаты.

Если я выйду и заново запустите приложение, все будет хорошо, и я смогу аутентифицироваться непосредственно как пользователь 2 и получить правильные результаты для user2. Единственный случай, который является проблемой, - это когда я выхожу из системы/регистрируюсь в качестве другого пользователя за один сеанс между мобильным приложением и сервером Worklight.

Является ли это известным ограничением использования базового auth с адаптерами Worklight? Могу ли я установить связь между мобильным клиентом и сервером Worklight для сброса при выходе из системы? (за исключением перезапуска приложения)

ответ

2

Поскольку вы говорите, что «физически» уходит и открывает приложение, это исправление для вас, то вы можете использовать WL.Client.reloadApp() сразу после выхода из системы, чтобы поддерживать поток приложений в случае входа в систему - авторизоваться. Посмотрите, помогает ли это.

+0

На Android, вызывая WL.Client.reloadApp() после выхода из системы, вы получаете новый JSessionId между мобильным приложением и сервером Worklight, а новый логин получает правильную информацию с обратной стороны. В iOS я не смог просмотреть сетевую трассировку, но я предполагаю, что WL.Client.reloadApp не приводит к новому сеансу между мобильным приложением и сервером подсветки, потому что второй пользователь должен войти в систему данные первого пользователя даже при вызове reloadApp() в обработчике выхода. –

+0

Только что получил трассировку сети на iOS. reloadApp() не приводит к новому сеансу между мобильным приложением и сервером подсветки (JSESSIONID остается прежним даже при вызове reloadApp), а второй пользователь все еще получает данные первого пользователя. Есть ли что-то, что я должен сделать в процедуре logout() адаптера для очистки сеанса подсветки? –

+1

Не знаю, в данный момент у нас есть дефект, зарегистрированный для этого сейчас. –

 Смежные вопросы

  • Нет связанных вопросов^_^