search

hbci4j / hbci4java

Java-based FinTS protocol implementation that supports all features (chipTAN, pushTAN, HHD, SEPA, PSD2,...)
GNU Lesser General Public License v2.1
146 stars 49 forks source link

NEED_PT_TANMEDIA wird nicht im ThreadedCallback behandelt #52

Closed guyyst closed 3 years ago

guyyst commented 3 years ago

Ich benutzte HBCI4Java in einer Server Umgebung mit Hilfe des ThreadedCallbacks Mechanismus (hier beschrieben), um Callbacks der Bank an den Client weiter zu leiten, welcher dann die entsprechende Information übergibt (TAN-Verfahren, TAN, Security Mechanism, etc.)

Wie es in diesem Kommentar beschrieben ist, kann es bei Callback Gründen vorkommen, dass die "echte" Callback Methode aufgerufen wird, anstatt die Threaded Variante, weil der callback nicht von der execute() Methode, sondern via z.B.: new HBCIHandler() erzeugt wurde.

Dieses Verhalten ist mir bereits aufgefallen bei den Callback Gründen NEED_USERID und NEED_PT_PIN, jedoch war es dort kein Problem, da ich dieses Daten sowieso mit dem initialen Client Aufruf mitschicke, und demnach schon bereit stehen habe.

Jetzt gerade habe ich jedoch eine Kontostandsabfrage über einen Online Banking Zugang der Sparkasse mit dem ChipTAN Verfahren machen wollen, und gemerkt, dass der Callback Grund NEED_PT_SECMECH ebenfalls nicht von execute() erzeugt wird, und demnach in der normalen Callback Methode behandelt wird, und nicht in der ThreadedCallback Methode.

NEED_PT_SECMECH retData: 910:chipTAN manuell|911:chipTAN optisch|912:chipTAN-USB|913:chipTAN-QR

Da in den Daten dieses Callbacks die möglichen Security Mechanismen enthalten sind, habe ich keine Möglichkeit die Antwort auf dieses Callback mit der initialen Client Anfrage mitzuschicken. Ich würde für diesen Callback Grund gerne die Execution pausieren, den Client nach der Präferenz fragen, und nach einer Antwort wieder continueThreaded() aufrufen. Aber so wie es jetzt steht, scheint das nicht Möglich zu sein.

Nach dem oben verlinkten Kommentar scheint der Threading Mechanismus für Erzeuger welche nicht execute() waren ja geplant zu sein. Gibt es dafür einen groben Zeitraum, oder andere Pläne dieses Problem zu beheben?

guyyst commented 3 years ago

In dem Moment wo ich auf Submit gedrückt habe ist mir der Fehler in meinem Gedankengang klar geworden...

Ich habe nicht darauf geachtet, dass dieses Problem einfach mit einer Präferenzspeicherung des Security Mechanisms gelöst wird, also kann man bei der aller ersten Anfrage einfach das erste Verfahren als Standard auswählen und den Nutzer danach bei Bedarf wechseln lassen.