HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für 9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)

1
2
Seite 1 von 2

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 17.09.2024 - 12:53 Uhr · #1

Hallo zusammen, vorab direkt: Ich benutze die neuste Version von hbci4java (3.1.82).

Die Taunus Sparkasse hat vor 1-2 Wochen angefangen "vertrauenswürdige" Geräte zu erzwingen, weswegen wir bei einem Konto bei dieser Sparkasse heute Morgen einen Aufruf zu "HBCIHandler::sync(force=true)" gemacht haben, um in der PushTAN App die Möglichkeit zu bekommen, unserer Applikation zu vertrauen.

Der Aufruf dieser Funktion hat auch korrekt den entsprechenden "Gerät als vertrauenswürdig speichern" Auftrag in der PushTAN App angezeigt, jedoch ist der Prozess nach Bestätigung in der App mit den folgenden Nachrichten fehlgechlagen:

Code

Meldung der Bank: 9050:Die Nachricht enthält Fehler.
Meldung der Bank: 9800:Dialog abgebrochen
Meldung der Bank: 9340:Ungültige Auftragsnachricht: Ungültige Signatur.
Meldung der Bank: 9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)
PIN-Fehler erkannt, Meldung der Bank: 9340: Ungültige Auftragsnachricht: Ungültige Signatur.

Daraus bin ich auch nach viel Googlen nicht schlauer geworden. Die Online-Banking PIN ist definitiv richtig, und bei einer falschen PIN hätte ich erwartet, dass man überhaupt nicht soweit kommt, dass ein Auftrag in der PushTAN App erscheint.

Andere Bankprozesse (Kontostand, Umsätze, etc.) brechen mit dem selben Fehler ab.

Hier die kompletten Logs:
Edit: Die kompletten Logs passen zwar in der Vorschau, werden beim posten aber truncated, also jetzt als Anhang:

Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.

OfflineBanker

Benutzer

Geschlecht: keine Angabe
Beiträge: 229
Dabei seit: 04 / 2012

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 17.09.2024 - 13:46 Uhr · #2

Erstmal danke für eine Anfrage mit Protokoll dabei. Das sieht man leider selten.

Ich würde sagen, die Ablehnung kommt daher dass ihr versucht einen HKSPA einzureichen obwohl der zuvor geschickte HKTAN-S (Statusrequest) noch "ausstehend" mitgeteilt hat. (Der gehörte zur HKVVB)
Ich fürchte der Auftrag ist noch nicht freigegeben zu dem Zeitpunkt. Normal wäre hier ja vorgesehen, dass man solange HKTAN-S aufruft bis man ein OK bekommt und die Auftragsantwort des Vorgängerauftrags abgerufen ist. Dann sollte erst der nächste Geschäftsvorfall aufgerufen werden.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10530
Dabei seit: 03 / 2005

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 17.09.2024 - 14:05 Uhr · #3

Die Ausführung des HKSPA kann mit "Feature.SYNC_SEPAINFO.setEnabled(false)" abgeschaltet werden. Normalerweise erfolgt das beim Sync nach dem erfolgreichen Abruf der UPD.

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 17.09.2024 - 14:40 Uhr · #4

Zitat geschrieben von hibiscus
Normalerweise erfolgt das beim Sync nach dem erfolgreichen Abruf der UPD.
Nur, damit ich das richtig verstehe: Diese Aussage bezieht sich auf die Ausführung des HKSPA, nicht auf das Deaktivieren von SYNC_SEPAINFO?
Der Kommentar an SYNC_SEPAINFO bezieht sich auf Probleme mit der Commerzbank. Ist es einfach möglich, dass manche Sparkassen jetzt änliche Probleme aufweisen?
Generell zu der Auslösung der Vertrauenswürdigkeitsprüfung der Sparkasse: Welcher Teil der HBCIUser::sync() Methode ist dafür zuständig diese Prüfung zu triggern? Wenn SYNC_SEPAINFO deaktiviert ist, wird in der sync Methode ja nur noch "fetchUPD()" aufgerufen und ein "HBCIProcessTanMedia" Prozess ausgeführt.

Aber vielen Dank für den Hinweis auf "SYNC_SEPAINFO", das werde ich zeitnah ausprobiern

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 17.09.2024 - 21:14 Uhr · #5

Okay, wir haben das ganze mit "Feature.SYNC_SEPAINFO.setEnabled(false)" probiert, und ein Aufruf zu "HBCIHandler::sync(force=true)" hat jetzt funktioniert, aber eine Kontostandsabfrage bricht immer noch mit dem selben Fehler ab.

Ich hänge der Vollständigkeit halber die log files für beide Aktionen an.

Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10530
Dabei seit: 03 / 2005

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 08:15 Uhr · #6

Die Bank antwortet mit "9340::Ungültige Auftragsnachricht?: Ungültige Signatur.". Die Meldung kenne ich im Zusammenhang mit falschem PIN/Passwort.

infoman

Benutzer

Geschlecht:
Beiträge: 7053
Dabei seit: 06 / 2008

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 09:15 Uhr · #7

Zitat geschrieben von hibiscus

Die Meldung kenne ich im Zusammenhang mit falschem PIN/Passwort.

ergänzend in diesem Zusammenhang:
a.) zu "alt"
b.) zu kurz
c.) zu lang (... und wird/wurde im Browser usw. abgeschnitten - dh. funktioniert fürs webbanking)
d.) Sonderzeichen (wird bei manchen Bank zugelassen, bei manchen nicht)
e.) Leerzeichen

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 10:14 Uhr · #8

Zitat geschrieben von hibiscus

Die Bank antwortet mit "9340::Ungültige Auftragsnachricht?: Ungültige Signatur.". Die Meldung kenne ich im Zusammenhang mit falschem PIN/Passwort.

Da ich persönlich nicht im Besitz der Zugangsdaten bin, kann ich das natürlich nicht zu 100% ausschließen, aber da wir es mittlerweile gut 10+ mal erfolglos versucht haben, und zwischendurch immer wieder erfolgreich ins Online-Banking gekommen sind, wäre ich sehr überrascht, wenn bei jedem Versuch die PIN falsch gewesen wäre.

Weiterhin haben wir ja erfolgreich einen Auftrag in der PushTAN App auslösen können, und nach meiner bisherigen Erfahrung mit Sparkassen Konten, würde man soweit ja überhaupt nicht kommen, wenn die Zugangsdaten Fehler haben.

Abgesehen davon hat der Zugang bis vor dieser Änderung am 09.09.2024 bei der Taunus Sparkasse noch funktioniert. Nach Gespräch mit dem Bankberater war die Förde Sparkasse in der selben "Batch" wie die Taunus Sparkasse bezüglich dieses Updates. Der selbe Berater hat nach einem Blick auf ihre Protokolle für die Fehlerhaften Verbindungen unserere Applikation auch keine Hinweise auf falsche Anmeldedaten gegeben. Aber wie gesagt, komplett ausschließen kann ich es nicht.

Zitat geschrieben von infoman

c.) zu lang (... und wird/wurde im Browser usw. abgeschnitten - dh. funktioniert fürs webbanking)

Moment, meinst du quasi, dass das Passwort, was im Webbanking auf der Sparkassen Seite eingegeben wurde, eigentlich zu lang ist, die Sparkasse schneidet es ab, und das gekürzte Passwort ist das richtige? Und das selbe lange Passwort wird von unserer Applikation ungekürzt, also falsch, übermittelt?

Das wäre... ziemlich verrückt von der Sparkasse :D

Aber wie oben bereits angedeutet, es wurde vor knapp 2 Wochen noch erfolgreich eine Sammellastschrift über diese Applikation eingereicht, und seitdem keine Zugangsdaten geändert.

OfflineBanker

Benutzer

Geschlecht: keine Angabe
Beiträge: 229
Dabei seit: 04 / 2012

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 10:26 Uhr · #9

Es hat nichts mit falschen PINs oder Benutzerkennungen zutun hier, sondern wie ich oben schon schrieb einen falschen Protokollablauf.

Auch in diesem Log ruft ihr wieder einen HKTAN-S auf und wartet nicht auf die Antwort nach der Freigabe. Es HITAN sagt noch "Ausstehend" und hat keine finale GV Antwort geliefert für HKVVB aber ihr fangt einfach an einen HKSAL zu schicken. Der wird wieder abgelehnt, weil er nicht erwartet wird.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10530
Dabei seit: 03 / 2005

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 10:32 Uhr · #10

Stimmt. hatte nur unten das HKSAL+HKTAN mit dem unmittelbar darauf folgenden Fehler gesehen. Weiter oben findet sich noch ein "3956::Starke Kundenauthentifizierung noch ausstehend.". Dann fehlt wahrscheinlich schlicht die Implementierung des Callbacks NEED_PT_DECOUPLED/NEED_PT_DECOUPLED_RETRY.

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 13:35 Uhr · #11

Zitat geschrieben von hibiscus

Dann fehlt wahrscheinlich schlicht die Implementierung des Callbacks NEED_PT_DECOUPLED/NEED_PT_DECOUPLED_RETRY.

Die beiden Callbacks sind definitiv implementiert. (Die PR für den NEED_PT_DECOUPLED_RETRY Callback kam übrigens von mir, falls Du den Namen nicht wiedererkannt hast :p)

Aber ich glaube wir kommen der Sache näher (vielen Dank schon mal für die bisherige Hilfe). Ich habe noch mal eine Umsatzabfrage über meine eigene Sparkasse gemacht, um erfolgreiche logs mit NEED_PT_DECOUPLED/NEED_PT_DECOUPLED_RETRY Callbacks zu bekommen (meine Sparkasse macht die Vertrauenswürdigkeitsprüfung noch nicht verpflichtend), und habe folgendes bemerkt:

Es folgt jeweils nur der Output meiner eigenen Applikation. Zuerst der erfolgreiche von meiner Sparkasse, wo ich nach 4 refresh requests den Auftrag in der App bestätigt habe:

Code

12:15:25,599 INFO (Thread-205) HBCI Thread: Creating HBCIHandler
12:15:25,651 INFO (Thread-205) HBCI Thread: Received callback reason: 16
12:15:25,659 INFO (Thread-205) HBCI Thread: Received callback reason: 24
12:15:26,522 INFO (Thread-205) HBCI Thread: Received callback reason: 25
12:15:26,539 INFO (Thread-205) HBCI Thread: Received callback reason: 24
12:15:27,231 INFO (Thread-205) HBCI Thread: Received callback reason: 32
12:15:30,770 INFO (Thread-205) HBCI Thread: Received callback reason: 25
12:15:30,771 INFO (Thread-205) HBCI Thread: Generating Job
12:15:30,783 INFO (Thread-205) HBCI Thread: Calling execute()
12:15:30,789 INFO (Thread-205) HBCI Thread: Received callback reason: 32
12:15:30,800 INFO (Thread-205) HBCI Thread: Received callback reason: 24
12:15:31,208 INFO (Thread-205) HBCI Thread: Received callback reason: 32
12:15:31,700 INFO (Thread-205) HBCI Thread: Received callback reason: 35
12:15:31,700 INFO (Thread-205) HBCI Thread: Received NEED_PT_DECOUPLED callback.
12:15:31,700 INFO (Thread-205) HBCI Thread: Sleeping HBCI thread for 2 seconds and then returning callback.
12:15:33,708 INFO (Thread-205) HBCI Thread: Finished NEED_PT_DECOUPLED sleep. Returning callback.
12:15:33,933 INFO (Thread-205) HBCI Thread: Received callback reason: 36
12:15:33,933 INFO (Thread-205) HBCI Thread: Received NEED_PT_DECOUPLED_RETRY callback.
12:15:33,934 INFO (Thread-205) HBCI Thread: Sleeping HBCI thread for 2 seconds and then returning callback.
12:15:35,943 INFO (Thread-205) HBCI Thread: Finished NEED_PT_DECOUPLED_RETRY sleep. Returning callback.
12:15:36,196 INFO (Thread-205) HBCI Thread: Received callback reason: 36
12:15:36,196 INFO (Thread-205) HBCI Thread: Received NEED_PT_DECOUPLED_RETRY callback.
12:15:36,196 INFO (Thread-205) HBCI Thread: Sleeping HBCI thread for 2 seconds and then returning callback.
12:15:38,200 INFO (Thread-205) HBCI Thread: Finished NEED_PT_DECOUPLED_RETRY sleep. Returning callback.
12:15:38,455 INFO (Thread-205) HBCI Thread: Received callback reason: 36
12:15:38,455 INFO (Thread-205) HBCI Thread: Received NEED_PT_DECOUPLED_RETRY callback.
12:15:38,455 INFO (Thread-205) HBCI Thread: Sleeping HBCI thread for 2 seconds and then returning callback.
12:15:40,459 INFO (Thread-205) HBCI Thread: Finished NEED_PT_DECOUPLED_RETRY sleep. Returning callback.
12:15:40,704 INFO (Thread-205) HBCI Thread: Received callback reason: 36
12:15:40,704 INFO (Thread-205) HBCI Thread: Received NEED_PT_DECOUPLED_RETRY callback.
12:15:40,704 INFO (Thread-205) HBCI Thread: Sleeping HBCI thread for 2 seconds and then returning callback.
12:15:42,717 INFO (Thread-205) HBCI Thread: Finished NEED_PT_DECOUPLED_RETRY sleep. Returning callback.
12:15:43,296 INFO (Thread-205) HBCI Thread: Received callback reason: 25
12:15:43,296 INFO (Thread-205) HBCI Thread: Awaking main thread with finished HBCI job.

Und als 2. der von der abgelehnten Kontostandsabfrage bei der Taunus Sparkasse:

Code

20:05:17,956 INFO (Thread-236) HBCI Thread: Creating HBCIHandler
20:05:18,008 INFO (Thread-236) HBCI Thread: Received callback reason: 16
20:05:18,015 INFO (Thread-236) HBCI Thread: Received callback reason: 24
20:05:18,588 INFO (Thread-236) HBCI Thread: Received callback reason: 25
20:05:18,597 INFO (Thread-236) HBCI Thread: Received callback reason: 24
20:05:18,922 INFO (Thread-236) HBCI Thread: Received callback reason: 32
20:05:19,290 INFO (Thread-236) HBCI Thread: Received callback reason: 32
20:05:19,298 INFO (Thread-236) HBCI Thread: Received callback reason: 35
20:05:19,298 INFO (Thread-236) HBCI Thread: Received NEED_PT_DECOUPLED callback.
20:05:19,299 INFO (Thread-236) HBCI Thread: Sleeping HBCI thread for 2 seconds and then returning callback.
20:05:21,300 INFO (Thread-236) HBCI Thread: Finished NEED_PT_DECOUPLED sleep. Returning callback.
20:05:21,537 INFO (Thread-236) HBCI Thread: Received callback reason: 25
20:05:21,538 INFO (Thread-236) HBCI Thread: Generating Job
20:05:21,551 INFO (Thread-236) HBCI Thread: Calling execute()
20:05:21,554 INFO (Thread-236) HBCI Thread: Received callback reason: 32
20:05:21,560 INFO (Thread-236) HBCI Thread: Received callback reason: 24
20:05:21,878 INFO (Thread-236) HBCI Thread: Received callback reason: 32
20:05:21,882 INFO (Thread-236) HBCI Thread: Received callback reason: 35
20:05:21,882 INFO (Thread-236) HBCI Thread: Received NEED_PT_DECOUPLED callback.
20:05:21,882 INFO (Thread-236) HBCI Thread: Sleeping HBCI thread for 2 seconds and then returning callback.
20:05:23,883 INFO (Thread-236) HBCI Thread: Finished NEED_PT_DECOUPLED sleep. Returning callback.
20:05:24,031 INFO (Thread-236) HBCI Thread: Received callback reason: 32
20:05:24,321 INFO (Thread-236) HBCI Thread: Received callback reason: 25
20:05:24,321 INFO (Thread-236) HBCI Thread: Awaking main thread with finished HBCI job.

Bei beiden logs sieht man nach erstellen des HBCIHandlers die erwarteten Callbacks (NEED_CONNECTION, NEED_PT_PIN, etc.), aber dann kommt der Unterschied: Bei meiner Sparkasse kommt nach NEED_PT_TANMEDIA(32) ein CLOSE_CONNECTION(25). Danach returned der HBCIHandler constructor und mein Applikationscode wird ausgeführt, woraufhin der eigentliche HBCIJob erstellt und executed wird. Kurz danach gibt es das erste NEED_PT_DECOUPLED(35) callback, gefolgt von 4 NEED_PT_DECOUPLED_RETRY(36).

Bei der Taunus Sparkasse hingegen gibt es nach NEED_PT_TANMEDIA direkt ein NEED_PT_DECOUPLED, bevor mein HBCIJob überhaupt gestartet wurde. Nach diesem decoupled callback kommt dann ein CLOSE_CONNECTION, und der HBCIHandler constructor returned. Jetzt wird der eigentliche Job ausgeführt, und hier gitb es dann ein *weiteres* NEED_PT_DECOUPLED callback. NEED_PT_DECOUPLED_RETRY erscheint überhaupt nicht. Also die GVTAN2Step::extractResults() Methode wurde quasi niemals aufgerufen.

Ich hänge beide vollständigen Log Files noch einmal an, dieses mal auch mit dem Output meiner Applikation, immer gepräfixt mit "HBCI Thread:"

Es sieht für mich etwas danach aus, als dass der UPD Sync im HBCIHandler constructor bei der Taunussparkasse eine PushTAN zur Vertrauenswürdigkeitsspeicherung auslöst, und dann returned, worauf hin der HBCIJob für die Kontostandsabfrage ebenfalls eine PushTAN Abfrage auslöst. Dabei kommt es dann zu Konflikten die ich nicht komplett verstehe.

Ist das ein zu erwartendes Verhalten? Und falls ja, kann ich irgendwie dafür sorgen, dass der HBCIHandler nicht returned, bevor die Decoupled request für die Vertrauenswürdigkeitsspeicherung akzeptiert würde?

Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10530
Dabei seit: 03 / 2005

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 13:51 Uhr · #12

Ich kenne deinen Code nicht und kann das daher nicht beurteilen. Du kannst es doch aber mal mit Hibiscus testen bzw. des den Kunden damit testen lassen, wenn du die Zugangsdaten selbst nicht hast.

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 16:17 Uhr · #13

Ich glaube, ich habe das Problem gefunden: hbci4java unterstützt soweit ich er erkenne bei einer SCA-Challange während der Dialog-Initialisierung nur das PROCESS2_STEP2 Verfahren, und behandelt ein Decoupled Verfahren genau so. Daher werden die `3956` Nachrichten der Bank quasi ignoriert.

Hier der Ablauf so wie ich ihn aus den Logs und dem Source Code verstehe:

Application Code ruft "new HBCIHandler()", und demnach HBCIHandler#registerUser() auf.
Darüber kommen wir zu HBCIUser#sync().
Hier werden als erstes über HBCIProcessTanMedia erfolgreich die TAN-Medienbezeichnung abgerufen.
Dann springen wir in HBCIUser#fetchUPD(), wo mit HBCIDialogInit eine Dialog-Initialisierung gesendet wird.
Hier gibt es in der Antwort der Bank den Unterschied zwischen meiner Sparkasse, und der Taunus Sparkasse:

Taunus Sparkasse:
Code
HBCI4JAVA INTERNAL: received message after decryption: HNHBK:1:3+000000000714+300+213048694500=330005106963CK0X=+1+213048694500=330005106963CK0X=:1'HNSHK:2:4+PIN:2+923+1366809690+1+1+2::399b861842fe42cb931bb8746a0204+1+1:20240917:200500+1:999:1+6:10:16+280:51250000:XX:S:0:0'HIRMG:3:2+3060::Bitte beachten Sie die enthaltenen Warnungen/Hinweise.+3920::Zugelassene Zwei-Schritt-Verfahren für den Benutzer.:923'HIRMS:4:2:5+3955::Auftrag empfangen - Bitte Auftrag in Ihrer App freigeben.(MBT62870200005)'HITAN:5:7:5+4++4521-09-17-20.05.00.102234+Bitte Auftrag in Ihrer App freigeben.+++Alle Geräte'HNSHA:6:2+1366809690'HNHBS:7:1+1'
Meine Sparkasse:
Code
HBCI4JAVA INTERNAL: received message after decryption: HNHBK:1:3+000000004161+300+739047039970=700037956963DFNK=+1+739047039970=700037956963DFNK=:1'HNSHK:2:4+PIN:2+923+1514031446+1+1+2::5ac7fa3c383b4d76814714849fd426+1+1:20240918:121530+1:999:1+6:10:16+280:36050105:XXXXXXXXXXXX:S:0:0'HIRMG:3:2+3060::Bitte beachten Sie die enthaltenen Warnungen/Hinweise.'HIRMS:4:2:4+3050::UPD nicht mehr aktuell, aktuelle Version enthalten.+3920::Zugelassene Zwei-Schritt-Verfahren für den Benutzer.:923+0020::Der Auftrag wurde ausgeführt.'HIRMS:5:2:5+3076::Starke Kundenauthentifizierung nicht notwendig.
Bei meiner Sparkasse sendet hbci4java hier nach Erkennung des `3076` codes ein DialogEnd, und der HBCIHandler constructor returned.
Bei der Taunus Sparkasse wird in der AbstractPinTanPassport#checkSCAResponse() Methode jetzt eine HITAN response erkannt, und eine TAN request getriggered.
Die Taunus Sparkasse antwortert dann mit `3956 - Starke Kundenauthentifizierung noch ausstehend`, da wir uns ja im Decoupled Verfahren befinden:

Code
HBCI4JAVA INTERNAL: received message after decryption: HNHBK:1:3+000000000573+300+213048694500=330005106963CK0X=+2+213048694500=330005106963CK0X=:2'HNSHK:2:4+PIN:2+923+2027286943+1+1+2::399b861842fe42cb931bb8746a0204+1+1:20240917:200502+1:999:1+6:10:16+280:51250000:XX:S:0:0'HIRMG:3:2+3060::Bitte beachten Sie die enthaltenen Warnungen/Hinweise.'HIRMS:4:2:3+3956::Starke Kundenauthentifizierung noch ausstehend.'HITAN:5:7:3+S++4521-09-17-20.05.00.102234'HNSHA:6:2+2027286943'HNHBS:7:1+2'
Der letze if Check in AbstractPinTanPassport#checkSCAResponse() wird erreicht, und "final SCA HITAN response found" in das log geschrieben.
Wir returnen in HBCIUser#fetchUPD() aus dem "init.execute(ctx)" call, wo jetzt der HBCIMsgStatus zu diesem Nachrichtenaustausch mit "if (!ret.isOK())" überprüft wird, aber da `3956` ja nur eine Warnuing und kein Error ist, glaubt hbci4java, alles ist Ok gelaufen und macht weiter. Es wird niemals nach dem `3956` return code gesucht um ein `NEED_PT_DECOUPLED_RETRY` callback zu triggern.
HBCIUser#fetchUPD() schickt ein HBCIDialogEnd und beendet den Dialog.
Wir returnen aus dem HBCIHandler constructor, und der eigentliche HBCIJob wird ausgeführt, obwohl der HBCIDialogInit beendet wurde, bevor der Nutzer die Challenge in der App bestätigen konnte.

infoman

Benutzer

Geschlecht:
Beiträge: 7053
Dabei seit: 06 / 2008

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 18.09.2024 - 19:25 Uhr · #14

auch wenn es in dem o.g. Fall anscheinend ja nicht die PIN ist

zu deiner Frage/Aussage: (abschließend)

Zitat geschrieben von guyyst

Das wäre... ziemlich verrückt

nunja die Information ist nicht neu @msa hat es bspw. hier schon 2015 gepostet
und betrifft nicht nur Sparkassen

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10530
Dabei seit: 03 / 2005

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 19.09.2024 - 08:43 Uhr · #15

Zitat geschrieben von guyyst

Der Rückmeldecode 3956 wird ja von der Bank verwendet, wenn die starke Kundenauthentifizierung im Decoupled-Verfahren noch ausstehend ist - der User in der App den Vorgang also noch nicht freigegeben hat. Wenn das der Fall ist, was soll denn dann anderes passieren, als dass das in einen Fehler läuft, wenn man den Vorgang trotzdem fortsetzt?

msa

Benutzer

Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7357
Dabei seit: 03 / 2007

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 19.09.2024 - 09:48 Uhr · #16

Zitat geschrieben von infoman

auch wenn es in dem o.g. Fall anscheinend ja nicht die PIN ist

zu deiner Frage/Aussage: (abschließend)

Zitat geschrieben von guyyst

Das wäre... ziemlich verrückt

nunja die Information ist nicht neu @msa hat es bspw. hier schon 2015 gepostet
und betrifft nicht nur Sparkassen

Das hat damals gegolten, inzwischen unterstützt und fordert FI längere PINs die eigentlich keine PINs mehr sondern Passwörter sind. Im Änderungsdialog kommt:

Zitat

Ihre neue Online-Banking-PIN
Bitte wählen Sie eine 5- bis 38-stellige Online-Banking-PIN, die nur Ihnen bekannt ist.

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 19.09.2024 - 13:12 Uhr · #17

Zitat geschrieben von hibiscus

Zitat geschrieben von guyyst

Aber man selbst hat den Vorgang doch nicht bewusst fortgesetzt, oder? Wenn innerhalb eines richtigen GV eine starke Kundenauthentifizierung ausstehend ist, wird hbci4java so lange einen NEED_PT_DECOUPLED_RETRY callback an die Applikation liefern, bis der Kunde den Auftrag bestätigt oder abgelehnt hat, da bei jeder 3956 response über diesen If-Check in der GVTAN2Step::extractResults() Methode der 3956 Code erkannt wird. Dann gibt es ein RERTY callback an die App und "this.redo = this;" sorgt für die Wiederholung der Refresh Nachricht.

Bei 3956 codes die als response auf eine Dialog-Initialisierung erhalten werden, wird diese Methode nie aufgerufen und keine decoupled retries versandt. Also wenn der User nicht innerhalb des aller ersten delays von dem initialen NEED_PT_DECOUPLED callback extrem schnell seine App öffnet, hat er quasi keine Chance den Auftrag zu bestätigen, weil hbci4java den Dialog sofort beendet.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10530
Dabei seit: 03 / 2005

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 19.09.2024 - 13:18 Uhr · #18

Das NEED_PT_DECOUPLED_RETRY hast du doch selbst in HBCI4Java implementiert. In Hibiscus nutze ich das nicht. Da gibt es also gar keine automatische Fortsetzung durch Pollen im Hintergruns sondern es geht erst weiter, wenn der User explizit bestätigt. Bisher hat mir auch kein Hibiscus-User von so einem Problem berichtet.

Vielleicht ist da einfach ein Fehler in deinem automatischen Retry per NEED_PT_DECOUPLED_RETRY.

guyyst

Benutzer

Geschlecht:
Beiträge: 9
Dabei seit: 09 / 2024

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 19.09.2024 - 13:35 Uhr · #19

Zitat geschrieben von hibiscus

Das ist quasi das, was ich bestätigen wollte: Der Fehler liegt in der Implementierung von dem NEED_PT_DECOUPLED_RETRY callback, da ich die library einfach nicht gut genug kannte um zu wissen, dass es Decoupled Challenges während der Dialog-Initialisierung geben kann, und weiterhin, dass es separates handling für Nachrichten von Dialog-Initialisierung und eigentlichen Geschäftsvorfällen gibt, so wie ich es in diesem Kommentar gelesen habe.

Ich schaue mir mir dieses Problem gerne genauer an, jedoch scheint nach dem Methoden-Kommentar der Pfad zur richtigen Lösung ja die Umstellung der HBCIDialog#doJobs() Methode auf RawHBCIDialoge, und da könnte meine fehlende Vertrautheit mit der library möglicherweise für eine weniger elegante Lösung sorgen :D

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10530
Dabei seit: 03 / 2005

Betreff:

Re: HBCIHandler::sync(force=true) sorgt bei Taunus Sparkasse für "9010:Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (3: SepaInfo.SEPAInfo1)"

· Gepostet: 19.09.2024 - 13:57 Uhr · #20

Zitat geschrieben von guyyst

Das ist quasi das, was ich bestätigen wollte: Der Fehler liegt in der Implementierung von dem NEED_PT_DECOUPLED_RETRY callback, da ich die library einfach nicht gut genug kannte um zu wissen, dass es Decoupled Challenges während der Dialog-Initialisierung geben kann, und weiterhin, dass es separates handling für Nachrichten von Dialog-Initialisierung und eigentlichen Geschäftsvorfällen gibt ...
Ich schaue mir mir dieses Problem gerne genauer an, jedoch scheint nach dem Methoden-Kommentar der Pfad zur richtigen Lösung ja die Umstellung der HBCIDialog#doJobs() Methode

GVTan2Step ist die Behandlung der TAN-Responses bei der Ausführung von konkreten Geschäftsvorfällen wie HKSAL. Das Pendant dazu bei der Dialoginitialisierung findet sich in AbstractPinTanPassport#checkSCAResponse. Dort müsste die Behandlung des Codes 3956 ebenfalls rein. Ich nehme an, irgendwie zwischen Zeile 656 und 687 https://github.com/hbci4j/hbci….java#L656
Dort wird ja das HITAN ausgewertet. Die Bank sollte das ja zusammen mit dem Code 3956 schicken, wenn die Freigabe noch nicht erfolgt ist. Daraufhin müsste das HKTAN erneut gesendet werden. Also vermutlich auch irgendwas mit ctx.setRepeat(true).

Aufgerufen wird "checkSCAResponse" als eine von mehreren Methoden in "onDialogEvent", sobald eine neue Nachricht von der Bank eingetroffen ist. Unter Umständen könnte man dort auch eine komplett neue Methode analog zu checkInvalidPIN, check3920, check3072, checkSCAResponse einbauen.

1
2
Seite 1 von 2