2017-02-08 2 views
1

У нас есть приложение для iOS для производства, которое в настоящее время работает под MFP 7.0. Я обновляю его до MFP 8.0.GatewayChallengeHandler: handleChallenge() не вызывается после обновления до MobileFirst v.8.0

В существующей версии мы добавляем ChallengeHander как ISAMChallengeHandler для обработки запросов входа в шлюз ISAM. Для v8.0 я изменил ISAMChallengeHandler для расширения GatewayChallengeHandler. Это связано с изменением isCustomResponse() на canHandleResponse() и удаление вызова submitFailure().

Новая версия не работает должным образом. Когда я вызываю адаптер с использованием WLClient.getInstance(). InvokeProcedure (...), шлюз возвращает экран входа в систему, а ISAMChallengeHandler.canHandleResponse() правильно вызывается и возвращает true. Но handleChallenge() никогда не вызывается.

Вместо этого выясняется, что HTTP-запрос к адаптеру снова попробовали, в результате чего был вызван другой вызов функции canHandleResponse(). Это происходит 7 раз подряд без какой-либо попытки вызвать handleChallenge(). Затем возникает ошибка из WLResourceRequest, а WLDelegate получает обратный вызов onFailure().

Что может быть причиной такого поведения? Логика приложения не изменилась с версии 7.0. Вызывается invokeProcedure() больше не поддерживается? Я получаю предупреждения об устаревании Xcode на wlConnectWithDelegate() и WLProcedureInvocationData(), но не invokeProcedure() (что не имеет смысла).

HTTP-попытки всегда бывают семь раз. Ниже приведены записи журнала из приложения, показывающие это. Я удалил строки «Response Content» для удобочитаемости. LoginManager - это класс, который вызывает invokeProcedure(), используя LoginListener как WLDelegate.

2017-02-07 20:41:41.613 sitecompliance[50592:4035152] <AppDelegate> App starting: Optional("1.0") Optional("309.2") 
2017-02-07 20:41:41.619 sitecompliance[50592:4035152] <AppDelegate> deviceDate (UTC): 2017-02-08 02:41:41 +0000 
2017-02-07 20:41:41.620 sitecompliance[50592:4035152] <AppDelegate> deviceDate (localtime): Feb 7, 2017, 8:41:41 PM 
2017-02-07 20:41:41.669 sitecompliance[50592:4035152] <LoginManager.connectAndLogin> 
2017-02-07 20:41:42.386 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning FALSE 
2017-02-07 20:41:43.595 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning FALSE 
2017-02-07 20:41:43.595 sitecompliance[50592:4035152] <ConnectListener.onSuccess> connectionSuccess 
2017-02-07 20:41:43.596 sitecompliance[50592:4035152] <LoginManager.connectionSuccess> 
2017-02-07 20:41:43.599 sitecompliance[50592:4035152] <LoginManager.authenticate> Invoking Worker/getWorker 
2017-02-07 20:41:44.469 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> Found "/pkmslogin.form" 
2017-02-07 20:41:44.470 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning TRUE 
2017-02-07 20:41:44.584 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> Found "/pkmslogin.form" 
2017-02-07 20:41:44.585 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning TRUE 
2017-02-07 20:41:44.682 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> Found "/pkmslogin.form" 
2017-02-07 20:41:44.682 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning TRUE 
2017-02-07 20:41:44.782 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> Found "/pkmslogin.form" 
2017-02-07 20:41:44.782 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning TRUE 
2017-02-07 20:41:44.878 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> Found "/pkmslogin.form" 
2017-02-07 20:41:44.878 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning TRUE 
2017-02-07 20:41:44.973 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> Found "/pkmslogin.form" 
2017-02-07 20:41:44.974 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning TRUE 
2017-02-07 20:41:45.075 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> Found "/pkmslogin.form" 
2017-02-07 20:41:45.076 sitecompliance[50592:4035152] <ISAMChallengeHandler.canHandleResponse> returning TRUE 
2017-02-07 20:41:45.076 sitecompliance[50592:4035152] [ERROR] [WORKLIGHT] -[WLResourceRequest requestFailed:error:] in WLResourceRequest.m:695 :: WL_OAUTH 
2017-02-07 20:41:45.094 sitecompliance[50592:4035152] <LoginListener.onFailure> Cannot retrieve a valid authorization header for header. Check resource and authorization server configuration. 
2017-02-07 20:41:45.095 sitecompliance[50592:4035152] <LoginViewController.loginFailure> System error. 

Вот это начало ISAMChallenger обработчика, показывающий canHandleResponse() и handleChallenge() методы:

class ISAMChallengeHandler: GatewayChallengeHandler 
{ 
    let baseURL: String! 

    override init(){ 
     baseURL = "\(getBaseURL()!)" 
     super.init(gatewayName: "HeaderAuthRealm") 
    } 

    override func canHandleResponse(response: WLResponse!) -> Bool 
    { 
     if response != nil { 
      if response.responseText != nil { 
       if response.responseText.rangeOfString("PKMS Administration: Expired Password") != nil { 
        MQALogger.log("<ISAMChallengeHandler.canHandleResponse> Found \"PKMS Administration: Expired Password\"") 
        MQALogger.log("<ISAMChallengeHandler.canHandleResponse> returning TRUE") 
        return true 
       } 
       if response.responseText.rangeOfString("/pkmslogin.form") != nil { 
        MQALogger.log("<ISAMChallengeHandler.canHandleResponse> Found \"/pkmslogin.form\"") 
        MQALogger.log("<ISAMChallengeHandler.canHandleResponse> returning TRUE") 
        return true 
       } 

      } 
     } 
     MQALogger.log("<ISAMChallengeHandler.canHandleResponse> returning FALSE") 
     return false 
    } 

    override func handleChallenge(response: WLResponse!) 
    { 
     //HPDIA0200W Authentication failed. You have used an invalid user name, password or client certificate. 
     let failedLogin = response.responseText.rangeOfString("HPDIA0200W") != nil 
     let passwordExpired = response.responseText.rangeOfString("PKMS Administration: Expired Password") != nil 
     let worker = Worker.getWorker() 

     if worker.authDataSet && !failedLogin && !passwordExpired 
     { 
      MQALogger.log("<ISAMChallengeHandler.handleChallenge> Sending stored login data to ISAM") 
      submitISAMAuthData() 
     } 
     else 
     { 
      MQALogger.log("<ISAMChallengeHandler.handleChallenge> A login screen form should appear") 
      if failedLogin { 
       needCredentials("Please check your credentials.") 
      } else if passwordExpired { 
       worker.password = nil 
       saveObjects() 
       notify("Password expired", 
        myMessage: "Change on ServiceArizona secure gateway, then sign into app again.", vc: nil) 
        { self.showLoginView() } 
      } else { 
       needCredentials(nil) 
      } 
     } 
    } 
+1

Вы ознакомились с учебным пособием по интеграции ISAM для v8.0 (включая образцы для Android и iOS? См. Здесь: https://mobilefirstplatform.ibmcloud.com/tutorials/en/product-integration/8.0/isam- интеграция/ –

+1

Наш существующий дизайн 7.0 похож на этот пример учебника, за исключением того, что мы не используем файлы cookie ltpa. Требуются ли они в 8.0? В любом случае проблема возникает при входе в систему (до того, как будет задействован ltpa). Основная проблема заключается в том, что наша реализация canHandleResponse() возвращает TRUE, но handleChallenge() никогда не вызывается. Эта логика находится в API. Может быть, это ошибка? –

+0

Возможно. Я предлагаю открыть PMR, чтобы принять это еще ... –

ответ

0

Наша архитектура имеет прокси-сервер впереди как сервера ISAM/WebSeal, так и сервера MFP. Прокси направляет каждый запрос MFP одному или другому в зависимости от того, должен ли он быть разрешен WebSeal. Это работает в MFP 7, но не MFP 8.

Мы обнаружили, что, если мы устанавливаем все MFP трафик, чтобы пройти через ISAM, то GatewayChallengeHandler работал должным образом, но это не было правильным решением для нашей окружающей среды ,

Небольшое исследование журнала прокси обнаружило, что API MFP 8 отправляет HTTP-запрос «pre-auth» на сервер после того, как canHandleResponse() возвращается, но до того, как вызывается handleChallenge(). Это было не ясно из документации или регистрации API. Прокси-сервер отправил этот предварительный запрос непосредственно на сервер MFP (а не ISAM).

Когда мы добавили правило прокси, чтобы отправить все предварительные запросы (/mfp/api/preauth/*) в ISAM, проблема GatewayChallengeHandler была исправлена, и мы могли бы сохранить наши незащищенные запросы MFP напрямую на сервер MFP.

1

Конструкция был изменен в 8.0 и LTPA является способ пойти в тот момент, для аутентификации мобильных первых ресурсов через ISAM. Класс, используемый для обработки пользовательских задач, - GatewayChallengeHandler(), который правильно используется в вашем примере.

Функция для сбора вызовов, отправленных из сети, должна обрабатываться с использованием canHandle(). Я вижу, в вашем примере используется canHandleResponse(). Я думаю, это может быть причиной того, что handleChallenge() не получает вызов в вашем коде.

Пожалуйста, ознакомьтесь с новой ссылкой, указанной в комментарии выше для примера кода.

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