check credentials

[kvogelsa]

Guten Morgen zusammen und erst einmal herzlichen Dank für das tolle Projekt und die ganze Arbeit.

Ich taste mich gerade heran und habe eine Frage.

Mein Gerüst sieht so aus: php läuft als Daemon und erhält seine Befehle über message_queue und returned die Ausgaben dahin. Läuft soweit.

Das gesamte System ist mandantenfähig, die Benutzer sollen also Ihre FinTS-Zugriffe selbst konfigurieren können.

Den Anfang macht $fints = new \Fhp\FinTsNew($options, $credentials); Mit korrekten credentials liefert $fints->getTanModes() die möglichen Methoden. Sind jedoch username und/oder PIN falsch, wird eine Fehlermeldung geschmissen.

Gibt es die Möglichkeit, den login() auf Fehler zu überprüfen bzw. den Fehler abzufangen?

[ampaze]

Du kannst die Exception einfach fangen und auswerten.

Eine andere Möglichkeit wäre

$action = $fints->login();
if ($action->isError()) {
    if ($action->getError()->hasError(Rueckmeldungscode::PIN_UNGUELTIG)) {
    }
}

[kvogelsa]

Danke für deine Antwort. Exception fangen ist mE keine Lösung. Die Fehlermeldung lautet

TypeError: Argument 3 passed to Fhp\BaseAction::processError() must be an instance of Fhp\Protocol\UPD, null given, called in /var/www/apigilityProxy/apigility/codeFolder/vendor/nemiah/php-fints/lib/Fhp/FinTsNew.php on line 280 in /var/www/apigilityProxy/apigility/codeFolder/vendor/nemiah/php-fints/lib/Fhp/BaseAction.php on line 218

Kann ich daraus den Fehler Username/Passwort falsch schließen?

Zu deinem 2. Ansatz: Den habe ich auch gefunden. Ich kann jedoch den login nicht durchführen, ohne zuvor das TAN-Medium festzulegen. Bevor ich das kann, muss ich available Tans wissen. MaW: Ich komme dar nicht dazu $fints->login() durchzuführen.

Noch eine Beobachtung (KSK Köln): Gebe ich den Benutzernamen richtig ein und nur das Passwort falsch, wird die Exception geschmissen. Ist der Benutzername falsch, werden 4 TAN-Medien angeboten, statt der einen richtigen. (Mutmaßlich alle TAN-Medien der KSK Köln).

[ampaze]

Ah ich dachte es ginge um eine Zugangsdaten-Falsch-Exception.

Die processError-Methode sieht folgendermaßen aus https://github.com/nemiah/phpFinTS/blob/8952cada3704307d02213ee4f41f495f977f23f4/lib/Fhp/BaseAction.php#L234

d.h. $upd darf durchaus Null sein. Hast du die aktuellste Version?

Edit: Momentan musst du master benutzen, da es noch keine neue Version gibt, siehe #197.

[kvogelsa]

Danke! Ich hatte über den Composer-Befehl installiert. Einfach die Master zu verwenden, hat geholfen.

Noch eine Frage dazu: Bei der KSK-Köln ist die PIN nicht erfordelrich, um die TAN-Modes zu holen. Es wird korrekt in die Logs geschrieben. Auch als meine PIN gesperrt war durch zu viele falsche Zugriffe, konnte ich die TAN-Modes holen.

Wäre das nicht eine Möglichkeit, gettanmodes() ohne PIN durchzuführen? Oder ist das eine Sondersuppe der KSK?

[ampaze]

Ich würde mal sagen, dass die TAN Modes prinzipiell schon vom jeweiligen Zugang abhängen können. Die Tan Modes nützen dir doch auch nichts wenn du danach eh nicht weiter machen kannst?

[kvogelsa]

Ja, ist richtig. Aber, zumindest bei der KSK, reicht der Benutzername, um die TAN-Modes abzurufen, die für diesen Benutzer möglich sind.

Ich gebe dir aber recht, dass sie mir dann im weiteren nichts nützen. Wäre nur eine Datum einmal weniger.

[Philipp91]

Ja, ist richtig. Aber, zumindest bei der KSK, reicht der Benutzername, um die TAN-Modes abzurufen, die für diesen Benutzer möglich sind.

Funktioniert es, wenn du als PIN einfach '' angibst?

Nachdem du die TAN-Modes gekriegt hast, musst du die FinTsNew-Instanz natürlich wegschmeißen und eine neue erstellen mit der richtigen PIN, sonst klappt der Login nicht.

Welchen Vorteil hat deine Anwendung, wenn sie die PIN zum Abrufen der TAN-Modes nicht wissen muss? Früher oder später muss man die PIN dann ja doch eingeben, oder?

[kvogelsa]

Ja, hatte ich ja geschrieben, dass ich die PIN später ohnehin brauche.

Mein Hintergrund war, dass ich nicht mittels CLI sondern über php/Apache arbeite. Der User soll also seine Bankdaten angeben, um auszuwählen, welche Konten er über meine SW verwalten will. Aus irgendeinem Grund wollte ich, dass der User seine PIN erst später eingibt. Genau nachvollziehen kann ich es ehrlich gesagt nicht mehr. Ich glaube, der Grund war, dass es insgesamt nicht funktionier hat, weil ich über composer die falsche Version gezogen hatte.

[Philipp91]

Der User soll also seine Bankdaten angeben, um auszuwählen, welche Konten er über meine SW verwalten will.

Beim Anruf der verfügbaren Konten sollte auf jeden Fall eine PIN verlangt werden, sonst kann man ja Kontonummer und Namen von anderen rausfinden nur weil man ihren Anmeldenamen erraten hat (oder Brute-Force).

Bei den TAN-Modes wie vorher diskutiert ist das eine andere Sache, die sind ja im Grunde unabhängig vom Nutzer. Und wir kriegen sie tatsächlich in BPD::allTanModes. Zusammen mit dem Nutzerlogin können wir dann aber die FinTsNew::allowedTanModes anbieten, also nur die Teilmenge die für den Nutzer wirklich freigeschalten ist. Das ist eine sicherheitsrelevante Information, denn damit weiß ein Angreifer, über welche Kanäle er es (bei gegebenem Nutzernamen) überhaupt versuchen muss, also macht es Sinn, die Information zumindest mit der PIN zu schützen.

In der Praxis haben vielen Banken nur einen oder wenige TAN-Modes. Wir könnten eine Funktion FinTsNew::getBpd() oder FinTsNew::getAllTanModes() einbauen, die nur eine Synchronisierung (ohne nutzerspezifische Daten) erfordert, dann könntest du deinen Nutzern die längere Liste zur Auswahl anbieten, und wenn du dann selectTanMode() mit einem Modus aufrufst, der für den Nutzer gar nicht freigeschaltet ist, dann gibt's halt nachträglich eine Exception.

[kvogelsa]

Ich weiß nicht, ob das nötig ist. Logisch wäre es allerdings, da die Bank die TAN-Modes ohne login herausgibt. Allerdings ist gar nicht klar, mir jedenfalls nicht, ob das alle Banken gleich machen.

[Philipp91]

@nemiah Vielleicht können wir doch zurück zu FinTsOptions und Credentials als separate Objekte, die man dem Konstruktor übergibt? Dann könnte man das nämlich so machen:

$options = FinTsOptions::create(...); // Bank-spezifische Informationen
$bpd = FinTs::getBpd($options);
echo "Wählen Sie einen TAN-Modus: " . $bpd->getTanModes();
$username = input("Bitte geben Sie den Nutzernamen ein");
$pin = input("Bitte geben Sie die PIN ein");
$credentials = Credentials::create($username, $pin);
$fints = new FinTs($options, $credentials);

Sprich man kann die BPD schon abholen und darauf basierend Entscheidungen treffen bevor der Nutzer seine Zugangsdaten eingeben musste. Und der Programmierer konnte $options zwei Mal verwenden ohne alle Parameter einzeln aufzulisten.

[NobodzzZ]

@nemiah Vielleicht können wir doch zurück zu FinTsOptions und Credentials als separate Objekte, die man dem Konstruktor übergibt? Dann könnte man das nämlich so machen:

$options = FinTsOptions::create(...); // Bank-spezifische Informationen
$bpd = FinTs::getBpd($options);
echo "Wählen Sie einen TAN-Modus: " . $bpd->getTanModes();
$username = input("Bitte geben Sie den Nutzernamen ein");
$pin = input("Bitte geben Sie die PIN ein");
$credentials = Credentials::create($username, $pin);
$fints = new FinTs($options, $credentials);

Sprich man kann die BPD schon abholen und darauf basierend Entscheidungen treffen bevor der Nutzer seine Zugangsdaten eingeben musste. Und der Programmierer konnte $options zwei Mal verwenden ohne alle Parameter einzeln aufzulisten.

Dachte mir direkt, warum soll die FinTsOptions und Credentials eigentlich entfernt werden, ist doch eine ordentliche Struktur.

[nemiah]

Ist ok, ich mache es mir dann schon schön :grin:

[Philipp91]

BPD-Abholen ohne Zugangsdaten ist jetzt möglich (Beispielcode).