GatewayChallengeHandler: handleChallenge() wird nach dem Upgrade auf MobileFirst v.8.0 nicht aufgerufen

Question

Wir verfügen über eine Produktions-iOS-App, die derzeit unter MFP 7.0 ausgeführt wird. Ich aktualisiere es auf MFP 8.0.

In der bestehenden Version erweitern wir ChallengeHander als ISAMChallengeHandler um ISAM-Gateway-Login-Anfragen zu bearbeiten. Für v8.0 habe ich ISAMChallengeHandler geändert, um GatewayChallengeHandler zu erweitern. Dies beinhaltete die Änderung von isCustomResponse() zu canHandleResponse() und das Entfernen eines Aufrufs von submitFailure().

Die neue Version funktioniert nicht wie erwartet. Wenn ich einen Adapter mit WLClient.getInstance() aufrufen. InvokeProcedure (...), gibt das Gateway den Anmeldebildschirm zurück und ISAMChallengeHandler.canHandleResponse() wird ordnungsgemäß aufgerufen und gibt True zurück. Aber handleChallenge() wird nie aufgerufen.

Stattdessen wird die HTTP-Anforderung an den Adapter erneut versucht, was zu einem weiteren Aufruf von canHandleResponse() führt. Dies geschieht 7 mal in Folge ohne den Versuch, handleChallenge() aufzurufen. Dann tritt ein Fehler von WLResourceRequest auf, und der WLDelegate ruft den onFailure() - Callback ab.

Was kann dieses Verhalten verursachen? Die Logik der Anwendung hat sich seit Version 7.0 nicht geändert. Wird invokeProcedure() nicht mehr unterstützt? Ich bekomme Xcode Deprecation Warnungen auf wlConnectWithDelegate() und WLProcedureInvocationData(), aber nicht invokeProcedure() (was keinen Sinn macht).

Die HTTP-Versuche finden immer sieben Mal statt. Unten sind die Protokolleinträge von der App, die dies zeigen. Ich habe die Zeilen "Response Content" für Readablility entfernt. LoginManager ist die Klasse, die invokeProcedure() mit LoginListener als WLDelegate aufruft.

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. 

Hier ist der Anfang der ISAMChallenger Handler die canHandleResponse() und handleChallenge zeigt() Methoden:

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) 
      } 
     } 
    } 

Answer 1

Unsere Architektur verfügt über einen Proxyserver vor dem ISAM/WebSeal-Server und dem MFP-Server. Der Proxy leitet jede MFP-Anforderung an den einen oder anderen Benutzer weiter, je nachdem, ob er von WebSeal autorisiert werden muss oder nicht. Dieser arbeitet in MFP 7 aber MFP nicht 8.en

Ich entdecken, dass, wenn wir all MFP Verkehr gesetzt bis zum ISAM zu gehen, dann ist der GatewayChallengeHandler richtig gearbeitet, aber das war keine gültige Lösung für unsere Umwelt .

Eine kleine Proxy-Protokolluntersuchung fand heraus, dass die MFP 8-API eine "Pre-Auth" -HTTP-Anfrage an den Server sendet, nachdem canHandleResponse() zurückkehrt, aber bevor handleChallenge() aufgerufen wird. Dies wurde aus den Dokumenten oder der API-Protokollierung nicht deutlich. Der Proxy sendet diese Vorautorisierungsanforderung direkt an den MFP-Server (nicht an den ISAM).Wenn wir eine Proxy-Regel hinzugefügt haben, um alle Pre-Auth-Anforderungen (/mfp/api/preauth/*) an ISAM zu senden, wurde das GatewayChallengeHandler-Problem behoben, und wir konnten unsere nicht gesicherten MFP-Anforderungen direkt an den MFP-Server weiterleiten.

Answer 2

Das Design in 8,0 und das LTPA ist der Weg zu gehen im Moment geändert wurde zum Authentifizieren von mobilen ersten Ressourcen über ISAM. Die Klasse, die für die Bearbeitung der benutzerdefinierten Herausforderungen verwendet wird, ist GatewayChallengeHandler(), die in Ihrem Beispiel korrekt verwendet wird.

Die Funktion zum Erfassen der vom Netzwerk gesendeten Probleme sollte unter Verwendung von canHandle() verarbeitet werden. Ich sehe, in Ihrer Probe wird canHandleResponse() verwendet. Ich nehme an, dass das der Grund sein kann, dass handleChallenge() in Ihrem Code nicht aufgerufen wird.

Bitte überprüfen Sie den neuen Link im Anhang für den Beispielcode angebracht.