Abfrage-Handler in iOS-Anwendungen implementieren

improve this page | report issue

Übersicht

Wenn Sie versuchen, auf eine geschützte Ressource zuzugreifen, sendet der Server (die Sicherheitsüberprüfung) eine Liste mit mindestens einer Abfrage an den Client zur Bearbeitung zurück.
Die Liste wird als JSON-Objekt empfangen, in dem die Namen der Sicherheitsüberprüfungen sowie optional weitere JSON-Daten enthalten sind.

{
  "challenges": {
    "SomeSecurityCheck1":null,
    "SomeSecurityCheck2":{
      "some property": "some value"
    }
  }
}

Der Client muss für jede Sicherheitsüberprüfung einen Abfrage-Handler registrieren.
Der Abfrage-Handler definiert das clientseitige Verhalten für die jeweilige Sicherheitsüberprüfung.

Abfrage-Handler erstellen

Ein Abfrage-Handler ist eine Klasse, die von MobileFirst Server gesendete Abfragen bearbeitet. Er zeigt beispielsweise eine Anmeldeanzeige an, erfasst Berechtigungsnachweise und übermittelt diese an die Sicherheitsüberprüfung.

In diesem Beispiel geht es um die Sicherheitsüberprüfung PinCodeAttempts, die im Abschnitt CredentialsValidationSecurityCheck implementieren definiert wurde. Die von dieser Sicherheitsüberprüfung gesendete Abfrage enthält die verbleibende Anzahl von Anmeldeversuchen (remainingAttempts) und optional eine Fehlernachricht (errorMsg).

Erstellen Sie eine Swift-Klasse, die SecurityCheckChallengeHandler erweitert:

open class PinCodeChallengeHandler : SecurityCheckChallengeHandlerSwift {

}

Abfrage bearbeiten

Die Mindestanforderung des Protokolls SecurityCheckChallengeHandler ist die Implementierung der Methode handleChallenge, die den Benutzer zur Angabe der Berechtigungsnachweise auffordert. Die Methode handleChallenge empfängt die JSON-Abfrage als Verzeichnis.

Im folgenden Beispiel wird der Benutzer in einem Alert aufgefordert, den PIN-Code einzugeben:

override open func handleChallenge(challengeResponse: [AnyHashable: Any]!) {
  var errorMsg : String
  if challengeResponse!["errorMsg"] is NSNull {
      errorMsg = "This data requires a PIN code."
    }
    else{
      errorMsg = challengeResponse!["errorMsg"] as! String
  }
  let remainingAttempts = challengeResponse!["remainingAttempts"] as! Int + 2;

  showPopup(errorMsg,remainingAttempts: remainingAttempts);
}

Die Implementierung von showPopup ist in der Beispielanwendung enthalten.

Wenn die Berechtigungsnachweise nicht stimmen, können Sie erwarten, dass das Framework erneut handleChallenge aufruft.

Antwort auf die Abfrage übergeben

Wenn die Berechtigungsnachweise auf der Benutzerschnittstelle erfasst wurden, verwenden Sie die Methode submitChallengeAnswer(answer: [NSObject : AnyObject]!) von WLChallengeHandler, um eine Antwort an die Sicherheitsüberprüfung zu senden. Im folgenden Beispiel erwartet PinCodeAttempts eine Eigenschaft mit der Bezeichnung pin, die den übergebenen PIN-Code enthält:

self.submitChallengeAnswer(["pin": pinTextField.text!])

Abfrage abbrechen

Es kann vorkommen, dass Sie dem Framework mitteilen möchten, dass diese Abfrage komplett verworfen werden soll, z. B., wenn auf eine Schaltfläche Cancel geklickt wird.

Rufen Sie zu diesem Zweck Folgendes auf:

self.cancel()

Fehlerbehandlung

In einigen Szenarien kann ein Fehler ausgelöst werden (z. B. bei Erreichung der maximalen Anzahl von Versuchen). Implementieren Sie für solche Fälle die Methode handleFailure von SecurityCheckChallengeHandler. Die Struktur des als Parameter übergebenen Verzeichnisses (Dictionary) hängt in starkem Maße von der Art des Fehlers ab.

override open func handleFailure(failureResponse: [AnyHashable: Any]!) {
    if let errorMsg = failureResponse["failure"] as? String {
        showError(errorMsg)
    }
    else{
        showError("Unknown error")
    }
}

Die Implementierung von showError ist in der Beispielanwendung enthalten.

Erfolgsbehandlung

Bei Bedarf können Sie entscheiden, eine Aktion auszuführen, bevor das Framework den Abfrage-Handler-Ablauf schließt, indem Sie die Methode handleSuccess(successResponse: [AnyHashable : Any]!) von SecurityCheckChallengeHandler implementieren. Auch hier sind Inhalt und Struktur der des Verzeichnisses “success” davon abhängig, was die Sicherheitsüberprüfung sendet.

Abfrage-Handler registrieren

Sie müssen das Framework anweisen, dem Abfrage-Handler den Namen einer bestimmten Sicherheitsüberprüfung zuzuordnen, damit der Abfrage-Handler auf dem Empfang der richtigen Abfragen wartet.

Initialisieren Sie den Abfrage-Handler dafür wie folgt mit der Sicherheitsüberprüfung:

var someChallengeHandler = SomeChallengeHandler(securityCheck: "securityCheckName”);

Anschließend müssen Sie die Abfrage-Handler-Instanz registrieren:

WLClientSwift.sharedInstance().registerChallengeHandler(challengeHandler: someChallengeHandler);

Geben Sie in diesem Beispiel Folgendes in einer Zeile ein:

WLClientSwift.sharedInstance().registerChallengeHandler(challengeHandler: PinCodeChallengeHandler(securityCheck: securityCheck));

Hinweis: Der Abfrage-Handler sollte im gesamten Anwendungslebenszyklus nur einmal registriert werden. Es wird empfohlen, dafür die iOS-AppDelegate-Klasse zu verwenden.

Beispielanwendung

PinCodeSwift ist eine iOS-Swift-Beispielanwendung, die WLResourceRequest verwendet, um einen Kontostand abzurufen.
Die Methode ist mit meinem PIN-Code geschützt, für den es maximal drei Eingabeversuche gibt.

Klicken Sie hier, um das Maven-Projekt SecurityAdapters herunterzuladen.
Klicken Sie hier, um das native iOS-Projekt PinCodeSwift herunterzuladen.

Verwendung des Beispiels

Anweisungen finden Sie in der Datei README.md zum Beispiel.

Beispielanwendung

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on November 29, 2019