-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PushTAN 2.0 (Decoupled) Dialog ended "erfolgreich" obwohl der Vorgang nicht in der App bestätigt wurde #91
Comments
Die Prüfung, ob die Freigabe in der PushTAN App durchgeführt wurde, ist schlicht nicht implementiert, da das den Aufwand deutlich erhöht hätte. Du kannst mir hierzu gern einen PR senden, welcher diesen Fall mit berücksichtigt. |
Danke für die schelle Antwort! Ich werde definitiv mal einen Blick in die Implementierung werfen. Nach meiner naiven Vorstellung muss hierfür ja "nur" bei der 3956 Nachricht wiederholt der Hast du irgendwelche Tipps/Hinweise, weswegen das ganze eigentlich komplexer ist? |
Du musst im Hintergrund einen zweiten Thread starten, den korrekt mit der aktuellen HBCI4Java-Session initialisieren und dann in zyklischen Abständen bei der Bank mit einem speziellen Dialog pollen, um den aktuellen Status abzufragen. Das gesamte Multi-Threading innerhalb einer HBCI-Session ist bisher gar nicht vorgesehen. |
Ah, verstehe. Das ist in sofern interessant, als das ich für meinen use-case diese Library bereits in einem multithreading context verwende. Ich starte den HBCI Dialog in einem neuen thread, welchen ich pausiere, wenn ein relevanter callback kommt. Dann kriegt der Nutzer im Frontend Bescheid, und mit der relevanten Antwort wird der thread, und damit auch der callback resumed. Demnach war meine Vorstellung von der Decoupled Implementierung in HBCI4Java komplett ohne threads. Es würde einfach bei jedem callback Return nach Entspricht das einfach nicht deiner Vorstellung von dem Decoupled Feature, oder gibt es technische Gründe, weswegen eine solche Implementierung problematisch wäre? |
Das weiss ich nicht. So genau habe ich das Thema nicht beleuchtet. |
Hallo @guyyst Bist Du mit dem Thema weitergekommen? Ich frage mich derzeit generell zwei Dinge:
Über einen Austausch würde ich mich sehr freuen. Viele Grüße, |
Hallo @ahachmann, ich bin, wie in meinem oberen Kommentar als Idee erwähnt, einen "einfacheren" Weg gegangen, indem ich lediglich den selben Job, welcher aktuell ja bereits 1 mal nach einem Meine Lösung basiert also zu 100% darauf, dass Nutzer der Library bei jedem Mein erster Ansatz für diese Implementierung ist hier, mit dem relevanten Task-Redo code in Ich bin mir nicht sicher wie akzeptabel dieser Ansatz für die Library ist, oder ob eine komplexere Multi-Threading Lösung mit automatischem Background-Refreshing erforderlich ist. Für meine Zwecke ist die von mir implementiere Funktionalität genau richtig, da meine Programm sich bereits um das Multi-Threading kümmert. @willuhn Vielleicht kannst du einen Blick drauf werfen und deine Meinung abgeben, bevor ich das ganze in einen Pull-Request Zustand bringe. Einige Fragen und Unsicherheiten habe ich eh noch bevor das ganze benutzbar wäre. |
Danke für den Code-Vorschlag. Ich glaube, ich verstehe ihn aber noch nicht.
|
|
Korrekt. Aber wie löst du diese HBCI-Nachricht nochmal erneut aus? Erstellst du hierfür in deinem Code nochmal separat ein "GVTAN2Step", das du dann manuell an die Bank sendest? Das muss ja eine einzelne HBCI-Nachricht sein, die nur genau das enthält. |
Ah verstehe, da habe ich mich auf den existierenden Code in |
Kannst du vielleicht mal ein Schnipsel des Codes von deiner Seite posten? Ich kann mir immer noch nicht so richtig erklären, wie du die Nachfrage-Nachricht auslöst. |
Also mein Verständnis des Ablaufs, durch welchen die Nachfrage-Nachricht wiederholt versandt wird, ist wie folgt:
Vielleicht verstehe ich hier irgendwas falsch, aber mit dem Debugger kann ich diese Schritte alle nachprüfen und die Logs geben den erfolgreich Versand der Nachricht auch wieder. |
Ah, jetzt. Ich hatte einfach das "this.redo = this" übersehen. OK, erstaunlich, dass das so funktioniert ;) Jetzt ist mir noch 1 Sache aufgefallen: Ich würde das Warten in HBCIPassportPinTan (Zeile 407ff) ersatzlos streichen. Grund: Das ist ja der erste Callback für die PushTAN. Zu dem Zeitpunkt ist noch nicht bekannt, ob überhaupt ein Retry notwendig sein wird. Das wissen wir erst, wenn das erste 3956 als Response eintrifft. Das ist in GVTAN2Step. Und dort wird ja dann auch gewartet (entweder direkt im Callback durch den Nutzer der API oder im Anschluss mit dem Thread.sleep). Das Sleep in HBCIPassportPinTan ist da aus meiner Sicht überflüssig. |
Bei dem Warten in Nachdem diese Statusabfrage eingereicht wurde, und wir daraufhin ein |
Das glaube ich nicht. Bisher habe ich es in Hibiscus ja auch komplett ohne Retry umgesetzt und ich beachte da auch die Retry-Zeiten nicht. Einfach deshalb, weil es da gar keinen Status-Request sondern nur die initiale PushTAN-Abfrage. Also User kriegt den TAN-Dialog in der App angezeigt, bestätigt in der App und danach in Hibiscus. Fertig. HKTAN wird eingereicht und die Bank genehmigt den Auftrag. Genau wie bisher bei allen anderen TAN-Verfahren auch. Nur eben, dass das HKTAN keine TAN mehr enthält. Soweit ist es in HBCIPassportPinTan umgesetzt. Die Prozessergänzung für die Retries kommt erst danach in's Spiel, falls der User in den Callbackl bestätigt hat, obwohl er in der App noch nicht freigegeben hat. Nur in dem Fall ist das Retry ja überhaupt nötig. Und erst dann muss gewartet werden. Also erst dann, wenn ein erneutes HKTAN an die Bank gesendet werden soll. |
Würdest du dann aber sagen, dass in |
Ja, so sollte es aus meiner Sicht implementiert sein. Beim ersten Retry decoupled_time_before_first_status_request alle folgenden decoupled_time_before_next_status_request. ich glaube allerdings nicht, dass es eine Bank gibt, die dort unterschiedliche Werte verwendet. Und wie bei deiner Bank werden die meisten Banken überhaupt keine relevanten Wartezeiten liefern. Ich denke, man könnte einfach pauschal decoupled_time_before_next_status_request verwenden - auch für den ersten. |
Es spricht ja nichts dagegen ruhig beide Werte zu verwenden, falls irgendwann eine Bank doch unterschiedliche Wartzeiten erfordert. Hab die Änderungen hier in einer PR hochgeladen. Alles weitere lässt sich dann ja dort besprechen. |
Ich bin gerade dabei das Decoupled Verfahren mit dem callback
NEED_PT_DECOUPLED
zu implementieren, und habe als aller erstes einmal probiert, was passiert wenn ich bei diesem Callback einfach nach einer kurzen Pause (10 Sekunden) direkt returne, ohne vorher in der PushTAN app den Auftrag zu bestätigen.Meine Erwartungshaltung ist (nachdem ich mir hier auch Kaptiel B.4.2.2 angeschaut habe), dass der callback
NEED_PT_DECOUPLED
dadurch immer wieder aufgerufen wird, bis der Prozess in der App besätigt wurde.In den unteren logs sieht man auch, dass die Bank mit
3956::Starke Kundenauthentifizierung noch ausstehend
geantwortet hat, aber daraufhin ist der nächste (und letzte) callbackCLOSE_CONNECTION
.Ein weiteres Problem ist danach, dass sowohl
HBCIJobResult::isOk()
, als auchHBCIDialogStatus::isOk()
true
zurückgeben, und es daher so aussieht, als wäre der Prozess erfolgreich bis zum Ende durchgelaufen. Also wäre eine separate Frage, mit welcher Methode ich vernünftig prüfen kann, dass der Bankprozess eigentlich Fehlerhaft, beziehungsweise unvollständig ist.Wenn ich während dem 10 Sekunden Buffer in der PushTAN app den Prozess bestätige klappt alles wie erwartet, nachdem der
NEED_PT_DECOUPLED
callback returned bekomme ich die erfolgreiche Antwort der Bank mit den angeforderten Daten.Die logs beginnen bei dem
NEED_PT_DECOUPLED
callback: hbci4java.logThe text was updated successfully, but these errors were encountered: