AbstractHBCICallback
, HBCICallbackConsole
, HBCICallbackIOStreams
, HBCICallbackNative
, HBCICallbackSwing
, HBCICallbackSwingInternal
, HBCICallbackThreaded
, HBCICallbackUnsupported
public interface HBCICallback
Schnittstelle, die eine Callback-Klasse implementieren muss. Beim Initialisieren von HBCI4Java
(HBCIUtils.init(Properties,org.kapott.hbci.callback.HBCICallback)
)
muss ein Callback-Objekt angegeben werden. Die Klasse dieses Objektes muss die HBCICallback-Schnittstelle
implementieren. Der HBCI-Kernel ruft in bestimmten Situationen Methoden dieser Klasse auf. Das ist
z.B. dann der Fall, wenn eine bestimmte Aktion (Einlegen der Chipkarte) oder Eingabe (Passwort)
vom Anwender erwartet wird. Außerdem werden auf diesem Weg Informationen an den Anwender weitergegeben
(Mitteilungen des Kreditinstitutes bei der Dialoginitialisierung).
Ein Anwendungsentwickler muss die Methoden dieser Schnittstelle also geeignet implementieren, um bei jeder möglichen Ursache für den Aufruf einer der Callback-Methoden sinnvoll zu reagieren. Dabei müssen nicht immer tatsächlich alle Anfragen an den Anwender weitergegeben werden. Ist z.B. das Passwort für die Schlüsseldatei eines Passports bereits bekannt, so kann die entsprechende Methode dieses Passwort direkt zurückgeben, ohne den Anwender erneut danach zu fragen.
Modifier and Type | Field | Description |
---|---|---|
static int |
CLOSE_CONNECTION |
Ursache des Callback-Aufrufes: die Netzwerk-Verbindung zum HBCI-Server wird nicht länger
benötigt.
|
static int |
HAVE_CHIPCARD |
Ursache des Callback-Aufrufes: Chipkarte wurde in Chipkartenterminal eingelegt.
|
static int |
HAVE_CRC_ERROR |
Ursache des Callback-Aufrufes: Fehler beim Verifizieren einer Kontonummer mit Hilfe
des jeweiligen Prüfzifferverfahrens.
|
static int |
HAVE_ERROR |
Ursache des Callback-Aufrufes: Es ist ein Fehler aufgetreten, der auf Wunsch
des Anwenders ignoriert werden kann.
|
static int |
HAVE_HARDPIN |
Ursache des Callback-Aufrufes: PIN-Eingabe über Chipkartenterminal abgeschlossen.
|
static int |
HAVE_IBAN_ERROR |
Ursache des Callbacks: beim Überprüfen einer IBAN ist ein Fehler aufgetreten.
|
static int |
HAVE_INST_MSG |
Ursache des Callback-Aufrufes: Institutsnachricht erhalten.
|
static int |
HAVE_NEW_MY_KEYS |
Ursache des Callback-Aufrufes: neue Nutzerschlüssel generiert (INI-Brief erforderlich).
|
static int |
NEED_BLZ |
Ursache des Callback-Aufrufes: Bankleitzahl der Bank benötigt.
|
static int |
NEED_CHIPCARD |
Ursache des Callback-Aufrufes: Chipkarte benötigt (im Chipkartenterminal).
|
static int |
NEED_CONNECTION |
Ursache des Callback-Aufrufes: es wird eine Netz-Verbindung zum HBCI-Server benötigt.
|
static int |
NEED_COUNTRY |
Ursache des Callback-Aufrufes: Länderkennzeichen der Bankverbindung benötigt.
|
static int |
NEED_CUSTOMERID |
Ursache des Callback-Aufrufes: Kunden-ID für HBCI-Zugang benötigt.
|
static int |
NEED_FILTER |
Ursache des Callback-Aufrufes: es wird die Bezeichnung des zu verwendenden
Datenfilters benötigt.
|
static int |
NEED_HARDPIN |
Ursache des Callback-Aufrufes: PIN-Eingabe am Chipkartenterminal erwartet.
|
static int |
NEED_HOST |
Ursache des Callback-Aufrufes: Netzwerkadresse des HBCI-Servers benötigt.
|
static int |
NEED_INFOPOINT_ACK |
Ursache des Callbacks: Kernel fragt um Erlaubnis, Daten an den InfoPoint-Server
zu senden.
|
static int |
NEED_NEW_INST_KEYS_ACK |
Ursache des Callback-Aufrufes: Bestätigung für neue Instituts-Schlüssel benötigt (INI-Brief-Vergleich).
|
static int |
NEED_PASSPHRASE_LOAD |
Ursache des Callback-Aufrufes: Passwort für das Einlesen der Schlüsseldatei
benötigt.
|
static int |
NEED_PASSPHRASE_SAVE |
Ursache des Callback-Aufrufes: Passwort für das Erzeugen der Schlüsseldatei
benötigt.
|
static int |
NEED_PORT |
Ursache des Callback-Aufrufes: TCP-Port, auf dem der HBCI-Server arbeitet (3000), benötigt.
|
static int |
NEED_PROXY_PASS |
Ursache des Callbacks: es wird ein Passwort für die Authentifizierung
am Proxy-Server benötigt.
|
static int |
NEED_PROXY_USER |
Ursache des Callbacks: es wird ein Nutzername für die Authentifizierung
am Proxy-Server benötigt.
|
static int |
NEED_PT_PHOTOTAN |
Ursache des Callback-Aufrufes: eine Photo-TAN für PIN/TAN-Verfahren benötigt.
|
static int |
NEED_PT_PIN |
Ursache des Callback-Aufrufes: PIN für PIN/TAN-Verfahren benötigt.
|
static int |
NEED_PT_SECMECH |
Ursache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss eines der
unterstützten Verfahren ausgewählt werden.
|
static int |
NEED_PT_TAN |
Ursache des Callback-Aufrufes: eine TAN für PIN/TAN-Verfahren benötigt.
|
static int |
NEED_PT_TANMEDIA |
Ursache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss
die Bezeichnung des TAN-Mediums eingegeben werden.
|
static int |
NEED_REMOVE_CHIPCARD |
Ursache des Callback-Aufrufes: Chipkarte soll aus Chipkartenterminal entfernt werden.
|
static int |
NEED_SIZENTRY_SELECT |
Ursache des Callback-Aufrufes: Auswahl eines Eintrages aus einer SIZ-RDH-Datei
benötigt.
|
static int |
NEED_SOFTPIN |
Ursache des Callback-Aufrufes: PIN-Eingabe über Computer-Tastatur benötigt.
|
static int |
NEED_USERID |
Ursache des Callback-Aufrufes: Nutzerkennung für HBCI-Zugang benötigt.
|
static int |
STATUS_DIALOG_END |
Kernel-Status: Beende Dialog.
|
static int |
STATUS_DIALOG_END_DONE |
Kernel-Status: Dialog beendet.
|
static int |
STATUS_DIALOG_INIT |
Kernel-Status: Starte Dialog-Initialisierung.
|
static int |
STATUS_DIALOG_INIT_DONE |
Kernel-Status: Dialog-Initialisierung ausgeführt.
|
static int |
STATUS_INIT_SIGID |
Kernel-Status: aktualisiere Signatur-ID.
|
static int |
STATUS_INIT_SIGID_DONE |
Kernel-Status: Signatur-ID aktualisiert.
|
static int |
STATUS_INIT_SYSID |
Kernel-Status: aktualisiere System-ID.
|
static int |
STATUS_INIT_SYSID_DONE |
Kernel-Status: System-ID aktualisiert.
|
static int |
STATUS_INIT_UPD |
Kernel-Status: hole UPD.
|
static int |
STATUS_INIT_UPD_DONE |
Kernel-Status: UPD aktualisiert.
|
static int |
STATUS_INST_BPD_INIT |
Kernel-Status: hole BPD.
|
static int |
STATUS_INST_BPD_INIT_DONE |
Kernel-Status: BPD aktualisiert.
|
static int |
STATUS_INST_GET_KEYS |
Kernel-Status: hole Institutsschlüssel.
|
static int |
STATUS_INST_GET_KEYS_DONE |
Kernel-Status: Institutsschlüssel aktualisiert.
|
static int |
STATUS_LOCK_KEYS |
Kernel-Status: sperre Nutzerschlüssel.
|
static int |
STATUS_LOCK_KEYS_DONE |
Kernel-Status: Nutzerschlüssel gesperrt.
|
static int |
STATUS_MSG_CREATE |
Kernel-Status: Erzeuge HBCI-Nachricht.
|
static int |
STATUS_MSG_CRYPT |
Kernel-Status: Verschlüssele HBCI-Nachricht.
|
static int |
STATUS_MSG_DECRYPT |
Kernel-Status: Entschlüssele HBCI-Nachricht.
|
static int |
STATUS_MSG_PARSE |
Kernel-Status: Parse HBCI-Antwort-Nachricht (bei diesem Callback ist das
passport -Objekt immer null ). |
static int |
STATUS_MSG_RAW_RECV |
Wird aufgerufen unmittelbar nachdem die HBCI-Nachricht vom Server empfangen wurde.
|
static int |
STATUS_MSG_RAW_SEND |
Wird aufgerufen unmittelbar bevor die HBCI-Nachricht an den Server gesendet wird.
|
static int |
STATUS_MSG_RECV |
Kernel-Status: Empfange HBCI-Antwort-Nachricht (bei diesem Callback ist das
passport -Objekt immer null ). |
static int |
STATUS_MSG_SEND |
Kernel-Status: Sende HBCI-Nachricht (bei diesem Callback ist das
passport -Objekt immer null ). |
static int |
STATUS_MSG_SIGN |
Kernel-Status: Signiere HBCI-Nachricht.
|
static int |
STATUS_MSG_VERIFY |
Kernel-Status: Überprüfe digitale Signatur der Nachricht.
|
static int |
STATUS_SEND_INFOPOINT_DATA |
Kernel-Status: Der Kernel sendet Informationen über eine erfolgreiche
Dialog-Initialisierung an den InfoPoint-Server (siehe auch README.InfoPoint).
|
static int |
STATUS_SEND_KEYS |
Kernel-Status: Sende Nutzerschlüssel.
|
static int |
STATUS_SEND_KEYS_DONE |
Kernel-Status: Nutzerschlüssel gesendet.
|
static int |
STATUS_SEND_TASK |
Kernel-Status: Erzeuge Auftrag zum Versenden.
|
static int |
STATUS_SEND_TASK_DONE |
Kernel-Status: Auftrag gesendet.
|
static int |
TYPE_BOOLEAN |
erwarteter Datentyp der Antwort: ja/nein, true/false, weiter/abbrechen
oder ähnlich.
|
static int |
TYPE_NONE |
erwarteter Datentyp der Antwort: keiner (keine Antwortdaten erwartet)
|
static int |
TYPE_SECRET |
erwarteter Datentyp der Antwort: geheimer Text (bei Eingabe nicht anzeigen)
|
static int |
TYPE_TEXT |
erwarteter Datentyp der Antwort: "normaler" Text
|
static int |
USERID_CHANGED |
im Parameter retData stehen die neuen Daten im Format UserID|CustomerID drin
|
static int |
WRONG_PIN |
Ursache des Callbacks: falsche PIN eingegeben
|
Modifier and Type | Method | Description |
---|---|---|
void |
callback(HBCIPassport passport,
int reason,
java.lang.String msg,
int datatype,
java.lang.StringBuffer retData) |
Wird vom HBCI-Kernel aufgerufen, wenn die Interaktion mit der
Anwendung erforderlich ist.
|
void |
log(java.lang.String msg,
int level,
java.util.Date date,
java.lang.StackTraceElement trace) |
Wird aufgerufen, wenn der HBCI-Kernel eine Log-Ausgabe
erzeugt.
|
void |
status(HBCIPassport passport,
int statusTag,
java.lang.Object o) |
Kurzform für
status(HBCIPassport, int, Object[]) für den Fall,
dass das Object[] nur ein einziges Objekt enthält |
void |
status(HBCIPassport passport,
int statusTag,
java.lang.Object[] o) |
Wird vom HBCI-Kernel aufgerufen, um einen bestimmten Status der
Abarbeitung bekanntzugeben.
|
boolean |
useThreadedCallback(HBCIPassport passport,
int reason,
java.lang.String msg,
int datatype,
java.lang.StringBuffer retData) |
Legt fest, ob ein Callback asynchron oder über den threaded-callback-Mechanismus
behandelt werden soll.
|
static final int NEED_CHIPCARD
HAVE_CHIPCARD
erzeugt.static final int NEED_HARDPIN
NEED_CHIPCARD
: Die Callback-Methode darf hier
nur eine entsprechende Meldung o.ä. anzeigen und muss dann sofort zurückkehren -- HBCI4Java erledigt die
eigentliche Entgegennahme der PIN. Wurde die PIN eingegeben (oder die Eingabe abgebrochen),
so wird ein weiterer Callback-Aufruf mit dem Code HAVE_HARDPIN
erzeugt.static final int NEED_SOFTPIN
NEED_HARDPIN
kann dieser Callback auftreten, wenn die direkte PIN-Eingabe
am Chipkartenterminal nicht möglich oder deaktiviert ist. In diesem Fall muss die PIN
"softwaremäßig" eingegeben werden, d.h. der Anwender gibt die PIN über die PC-Tastatur
ein, welche über diesen Callback-Aufruf an den HBCI-Kernel übergeben wird. Der Kernel
übermittelt die PIN anschließend zur Verifikation an die Chipkarte. In diesem Falle gibt es
keinen weiteren Callback-Aufruf, wenn die PIN-Verifikation abgeschlossen ist!static final int HAVE_HARDPIN
static final int HAVE_CHIPCARD
static final int NEED_COUNTRY
static final int NEED_BLZ
static final int NEED_HOST
https://
" weggelassen werden (also beispielsweise
"www.hbci-kernel.de/pintan/PinTanServlet
").static final int NEED_PORT
static final int NEED_USERID
static final int NEED_NEW_INST_KEYS_ACK
Beim Auftreten dieses Callbacks muss die Anwendung also die gerade empfangenen Schlüsseldaten der
Bank (öffentlicher Signier-/Chiffrierschlüssel) geeignet anzeigen (Exponent, Modulus, Hash-Wert) und
den Anwender auffordern, diese Daten mit denen aus dem INI-Brief zu vergleichen. Dieser Callback
erwartet als Rückgabedaten einen Boolean-Wert (siehe TYPE_BOOLEAN
). Sind die Daten
in Ordnung, so muss die Callback-Methode einen leeren String in dem Rückgabedaten-StringBuffer
zurückgeben, ansonsten füllt sie den StringBuffer mit einem beliebigen nichtleeren String (siehe dazu
callback(org.kapott.hbci.passport.HBCIPassport,int,String,int,StringBuffer)
und
die Beschreibung des Rückgabe-Datentyps TYPE_BOOLEAN
)).
Da im Moment keine dokumentierten Methoden zur Verfügung stehen, um aus einem Passport die
entsprechenden Schlüsseldaten zum Anzeigen zu extrahieren, wird folgendes Vorgehen empfohlen:
die Anwendung erzeugt eine HBCICallback-Klasse, die von einer der bereits vorhandenen
Default-Implementationen (HBCICallbackConsole
,
HBCICallbackSwing
, ...) abgeleitet ist. Tritt dieser Callback
auf, so kann die Anwendung mit super.callback(...)
die bereits implementierte
Version des entsprechenden Handlers aufrufen. In diesen Default-Implementationen werden zur Zeit
nicht dokumentierte Passport-Funktionen benutzt, um die Schlüsseldaten zu extrahieren.
static final int HAVE_NEW_MY_KEYS
Nach der Schlüsselerzeugung und dem erfolgreichen Versand der Schlüsseldaten erzeugt HBCI4Java
also diesen Callback. Die Anwendung muss in diesem Fall den Anwender darüber informieren, dass
seine neuen Schlüssel erst dann freigeschaltet werden, wenn er einen entsprechenden INI-Brief
generiert und zur Bank geschickt hat (und diese die Schlüsseldaten auf Übereinstimmung verglichen
hat). Zum Generieren eines INI-Briefes kann das Tool INILetter
benutzt werden, was Teil von HBCI4Java ist.
Nachdem dieser Callback abgearbeitet wurde, wirft HBCI4Java eine Exception (NeedKeyAckException
)
und bricht damit die Ausführung des aktuellen HBCI-Dialoges ab. Ein HBCI-Dialog zum Ausführen von
Geschäftsvorfällen kann erst dann wieder stattfinden, wenn die Bank die Schlüssel freigeschaltet hat.
Wird ein HBCI-Dialog begonnen, obwohl die Bank die neuen Schlüssel noch nicht aktiviert hat,
wird der HBCI-Server mit einer entsprechenden Fehlermeldung beim Initialisieren des HBCI-Dialoges
antworten.
static final int HAVE_INST_MSG
msg
-Parameter der callback
-Methode (siehe
callback(org.kapott.hbci.passport.HBCIPassport,int,String,int,StringBuffer)
einen
String, den die Bank als Kreditinstitutsnachricht an den Kunden gesandt hat. Diese Nachricht sollte
dem Anwender i.d.R. angezeigt werden. HBCI4Java erwartet auf diesen Callback keine Antwortdaten.static final int NEED_REMOVE_CHIPCARD
static final int NEED_PT_PIN
static final int NEED_PT_TAN
static final int NEED_CUSTOMERID
static final int HAVE_CRC_ERROR
Ursache des Callback-Aufrufes: Fehler beim Verifizieren einer Kontonummer mit Hilfe
des jeweiligen Prüfzifferverfahrens. Tritt dieser Callback auf, so hat HBCI4Java
festgestellt, dass eine verwendete Kontonummer den Prüfziffercheck der dazugehörigen Bank nicht
bestanden hat. Der Anwender soll die Möglichkeit erhalten, die Kontonummer und/oder
Bankleitzahl zu korrigieren. Dazu wird ein String in der Form "BLZ|KONTONUMMER" im Parameter
retData
der callback
-Methode übergeben. Die Anwendung kann dem
Anwender also BLZ und Kontonummer anzeigen und diese evtl. ändern lassen. Die neue BLZ und
Kontonummer muss im Ergebnis wieder in der o.g. Form in die Rückgabevariable
retData
eingetragen werden. Wurden BLZ oder Kontonummer geändert,
so führt HBCI4Java eine erneute Prüfung der Daten durch - schlägt diese
wieder fehl, so wird der Callback erneut erzeugt, diesmal natürlich mit den neuen
(vom Anwender eingegebenen) Daten. Werden die Daten innerhalb der Callback-Methode nicht
geändert (bleibt also der Inhalt von retData
unverändert), so übernimmt
HBCI4Java die Kontodaten trotz des fehlgeschlagenen Prüfziffern-Checks
Die automatische Überprüfung von Kontonummern findet statt, wenn HBCI-Jobs mit
Hilfe des Highlevel-Interfaces (siehe dazu Paketbeschreibung von org.kapott.hbci.GV
)
erzeugt werden. Beim Hinzufügen eines so erzeugten Jobs zur Menge der auszuführenden
Aufträge
(HBCIJob.addToQueue()
)
wird die Überprüfung für alle in diesem Job benutzten Kontonummern durchgeführt. Für jeden
Prüfzifferfehler, der dabei entdeckt wird, wird dieser Callback erzeugt.
Tritt beim Überprüfen einer IBAN ein Fehler auf, wird statt dessen
HAVE_IBAN_ERROR
als Callback-Reason verwendet.
static final int HAVE_ERROR
Ursache des Callback-Aufrufes: Es ist ein Fehler aufgetreten, der auf Wunsch
des Anwenders ignoriert werden kann. Durch Setzen bestimmter Kernel-Parameter
(siehe HBCIUtils.setParam(String,String)
) kann
festgelegt werden, dass beim Auftreten bestimmter Fehler zur Laufzeit nicht sofort eine Exception
geworfen wird, sondern dass statt dessen erst dieser Callback erzeugt wird, welcher als msg
eine entsprechende Problembeschreibung enthält. HBCI4Java erwartet einen
boolschen Rückgabewert, der beschreibt, ob der Fehler ignoriert werden soll oder ob eine
enstprechende Exception erzeugt werden soll. Der Anwender kann den Fehler ignorieren, indem
im retData
Rückgabedaten-Objekt ein leerer String zurückgegeben wird, oder er kann
erzwingen, dass HBCI4Java tatsächlich abbricht, indem ein nicht-leerer String im
retData
-Objekt zurückgegen wird. Siehe dazu auch die Beschreibung des
Rückgabe-Datentyps TYPE_BOOLEAN
.
Das Ignorieren eines Fehlers kann dazu führen, dass HBCI4Java später trotzdem eine Exception erzeugt, z.B. weil der Fehler in einem bestimmten Submodul doch nicht einfach ignoriert werden kann, oder es kann auch dazu führen, dass Aufträge von der Bank nicht angenommen werden usw. Es wird aber in jedem Fall eine entsprechende Fehlermeldung erzeugt.
static final int NEED_PASSPHRASE_LOAD
static final int NEED_PASSPHRASE_SAVE
static final int NEED_SIZENTRY_SELECT
Ursache des Callback-Aufrufes: Auswahl eines Eintrages aus einer SIZ-RDH-Datei benötigt. Dieser Callback tritt nur bei Verwendung der Passport-Variante SIZRDHFile auf. In einer SIZ-RDH-Schlüsseldatei können mehrere HBCI-Zugangsdatensätze gespeichert sein. Wird eine solche Datei mit mehreren Datensätzen geladen, so wird dieser Callback erzeugt, um den zu benutzenden Datensatz aus der Datei auswählen zu können.
Dazu wird beim Aufruf der Callback-Routine im Parameter retData
ein String übergeben, der aus Informationen über alle in der Datei vorhandenen
Zugangsdatensätze besteht. Das Format dieses Strings ist
<ID>;<BLZ>;<USERID>[|<ID>;<BLZ>;<USERID>...]
Es werden also die verschiedenen Datensätze durch "|" getrennt dargestellt,
wobei jeder einzelne Datensatz durch eine ID, die Bankleitzahl und die UserID
dieses Datensatzes repräsentiert wird.
Dem Anwender müssen diese Daten in geeigneter Weise zur Auswahl angezeigt
werden. Die Callback-Routine muss schließlich die ID des vom Anwender ausgewählten
Eintrages im retData
-Rückgabedatenobjekt zurückgeben.
Beim Aufruf der Callback-Routine könnte retData
also folgendes
enthalten: 0;09950003;Kunde-001|1;01234567;Kunde8|4;8765432;7364634564564
.
Der Anwender muss sich also zwischen den Datensätzen "09950003;Kunde-001",
"01234567;Kunde8" und "8765432;7364634564564" entscheiden. Je nach Auswahl
muss in retData
dann jeweils "0", "1" oder "4" zurückgegeben werden.
static final int NEED_CONNECTION
Ursache des Callback-Aufrufes: es wird eine Netz-Verbindung zum HBCI-Server benötigt.
Dieser Callback wird erzeugt, bevor HBCI4Java eine Verbindung zum HBCI-Server
aufbaut. Bei Client-Anwendungen, die mit einer Dialup-Verbindung zum Internet arbeiten,
kann dieser Callback benutzt werden, um den Anwender zum Aktivieren der Internet-Verbindung
aufzufordern. Es werden keine Rückgabedaten erwartet. Sobald die Internet-Verbindung
nicht mehr benötigt wird, wird ein anderer Callback (CLOSE_CONNECTION
) erzeugt.
Dieses Callback-Paar wird immer dann erzeugt, wenn von der aktuellen
HBCI4Java-Verarbeitungsstufe tatsächlich eine Verbindung zum Internet benötigt
wird bzw. nicht mehr (CLOSE_CONNECTION
) benötigt wird. U.U. werden allerdings
mehrere solcher Verarbeitungsstufen direkt hintereinander ausgeführt - das kann zur Folge
haben, dass auch diese Callback-Paare mehrmals direkt hintereinander auftreten. Das tritt
vor allem beim erstmaligen Initialiseren eines Passports auf. Beim Aufruf von
new HBCIHandler(...)
werden verschiedene Passport-Daten mit
der Bank abgeglichen, dabei wird u.U. mehrmals
NEED_CONNECTION
/CLOSE_CONNECTION
aufgerufen. Evtl.
sollte der Callback-Handler der Anwendung in diesem Fall also entsprechende
Maßnahmen treffen.
static final int CLOSE_CONNECTION
NEED_CONNECTION
benutzt werden, um für Clients mit Dialup-Verbindungen
die Online-Zeiten zu optimieren. Bei diesem Callback werden keine Rückgabedaten
erwartetstatic final int NEED_FILTER
Ursache des Callback-Aufrufes: es wird die Bezeichnung des zu verwendenden
Datenfilters benötigt. Mögliche Filterbezeichnungen sind "None
"
(kein Filter) und "Base64
" (Daten BASE64-kodieren). Die
jeweilige Filterbezeichnung ist in retData
zurückzugeben.
Dieser Callback tritt zur Zeit nur bei Verwendung von PIN/TAN-Passports
auf, weil hier nicht alle Banken einheitlich mit der gleichen Art der
Filterung arbeiten.
Normalweise wird bei PIN/TAN der Base64
-Filter benutzt.
Wenn bei dessen Verwendung aber keine Antwortdaten von der Bank empfangen
werden, dann sollte die andere Variante (None
) ausprobiert
werden.
static final int NEED_PT_SECMECH
Ursache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss eines der unterstützten Verfahren ausgewählt werden. Seit FinTS-3.0 gibt es mehrere Verfahren für PIN/TAN - das "normale" Einschrittverfahren sowie mehrere Zweischritt-Verfahren. Unterstützt eine Bank mehr als ein Verfahren, so wird dieser Callback erzeugt, damit der Anwender das zu verwendende Verfahren auswählen kann.
Dazu wird in retData
ein String mit folgendem Format
an die Callback-Methode übergeben:
"ID1:Beschreibung1|ID2:Beschreibung2...
". Jedes Token
"ID:Beschreibung
" steht dabei für ein unterstütztes
PIN/TAN-Verfahren. Die Callback-Methode muss die ID des vom Anwender
ausgewählten PIN/TAN-Verfahrens anschließend in retData
zurückgeben.
static final int NEED_PROXY_USER
client.passport.PinTan.proxyuser
gesetzt wurdestatic final int NEED_PROXY_PASS
client.passport.PinTan.proxypass
gesetzt wurdestatic final int HAVE_IBAN_ERROR
retData
wird die fehlerhafte IBAN übergeben. Der Nutzer
sollte die IBAN korrieren. Die korrigierte IBAN sollte wieder in retData
zurückgegeben werden. Wird die IBAN nicht verändert, wird diese IBAN trotz
des Fehlers verwendet. Wird eine korrigierte IBAN zum Nutzer zurückgegeben,
wird für diese erneut ein Prüfsummencheck ausgeführt. Schlägt der wieder fehl,
wird der Callback erneut erzeugt. Das geht so lange, bis entweder der
Prüfsummencheck erfolgreich war oder bis die IBAN vom Nutzer nicht verändert
wird. Siehe dazu auch HAVE_CRC_ERROR
.static final int NEED_INFOPOINT_ACK
infoPoint.enabled
" und Datei README.InfoPoint).
Bei diesem Callback wird im StringBuffer retData
das XML-Document
übergeben, welches an den InfoPoint-Server gesendet werden soll. Als Antwort
wird ein Boolean-Wert erwartet (siehe TYPE_BOOLEAN
). Dürfen die
Daten gesendet werden, ist von der Anwendung also ein leerer String in
retData
zurückzugeben, ansonsten ein beliebiger nicht-leerer String.static final int NEED_PT_TANMEDIA
Ursache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss die Bezeichnung des TAN-Mediums eingegeben werden. Bei smsTAN ist das z.Bsp. der Alias-Name des Mobiltelefons, wie er bei der Bank hinterlegt wurde. Dieser Name wird verwendet, damit die SMS mit der TAN an mehrere Mobiltelefone schicken kann.
static final int NEED_PT_PHOTOTAN
static final int WRONG_PIN
Ursache des Callbacks: falsche PIN eingegeben
static final int USERID_CHANGED
im Parameter retData stehen die neuen Daten im Format UserID|CustomerID drin
static final int TYPE_NONE
static final int TYPE_SECRET
static final int TYPE_TEXT
static final int TYPE_BOOLEAN
erwarteter Datentyp der Antwort: ja/nein, true/false, weiter/abbrechen
oder ähnlich. Da das
Rückgabedatenobjekt immer ein StringBuffer
ist, wird hier
folgende Kodierung verwendet: die beiden möglichen Werte für die
Antwort (true/false, ja/nein, weiter/abbrechen, usw.) werden dadurch
unterschieden, dass für den einen Wert ein leerer String
zurückgegeben wird, für den anderen Wert ein nicht leerer
beliebiger String. Einige Callback-Reasons können auch den Inhalt
des nicht-leeren Strings auswerten. Eine genaue Beschreibung der jeweilis
möglichen Rückgabedaten befinden sich in der Beschreibung der
Callback-Reasons (HAVE_*
bzw. NEED_*
), bei
denen Boolean-Daten als Rückgabewerte benötigt werden.
Siehe dazu auch die Hinweise in der Paketbeschreibung zum Paket
org.kapott.hbci.callback
.
static final int STATUS_SEND_TASK
HBCIJob
-Objekt des
Auftrages übergeben, dessen Auftragsdaten gerade erzeugt werden.static final int STATUS_SEND_TASK_DONE
HBCIJob
-Objekt des jeweiligen Auftrages übergeben.static final int STATUS_INST_BPD_INIT
HBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
)
auftreten und zeigt an, dass die BPD von der Bank abgeholt werden müssen,
weil sie noch nicht lokal vorhanden sind. Es werden keine zusätzlichen
Informationen übergeben.static final int STATUS_INST_BPD_INIT_DONE
STATUS_INST_BPD_INIT
) auf und kann auch nach einer
Dialog-Initialisierung auftreten, wenn dabei eine neue BPD vom Kreditinstitut
empfangen wurde. Als Zusatzinformation wird ein Properties
-Objekt
mit den neuen BPD übergeben.static final int STATUS_INST_GET_KEYS
HBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
)
und bei Verwendung von RDH als Sicherheitsverfahren auftreten. Es werden keine
zusätzlichen Informationen übergeben.static final int STATUS_INST_GET_KEYS_DONE
STATUS_INST_GET_KEYS
) oder nach einer Dialog-Initialisierung
auftreten, wenn das Kreditinstitut neue Schlüssel übermittelt hat. Es
werden keine zusätzlichen Informationen übergeben.static final int STATUS_SEND_KEYS
static final int STATUS_SEND_KEYS_DONE
HBCIMsgStatus
)
als Zusatzinformation übergeben.static final int STATUS_INIT_SYSID
HBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
)
auftreten. Es werden keine Zusatzinformationen übergeben.static final int STATUS_INIT_SYSID_DONE
STATUS_INIT_SYSID
) eine System-ID empfangen wurde. Als
Zusatzinformation wird ein Array übergeben, dessen erstes Element die Statusinformation
zu diesem Nachrichtenaustausch darstellt (HBCIMsgStatus
)
und dessen zweites Element die neue System-ID ist.static final int STATUS_INIT_UPD
HBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
)
auftreten und zeigt an, dass die UPD von der Bank abgeholt werden müssen,
weil sie noch nicht lokal vorhanden sind. Es werden keine zusätzlichen
Informationen übergeben.static final int STATUS_INIT_UPD_DONE
STATUS_INIT_UPD
) auf und kann auch nach einer
Dialog-Initialisierung auftreten, wenn dabei eine neue UPD vom Kreditinstitut
empfangen wurde. Als Zusatzinformation wird ein Properties
-Objekt
mit den neuen UPD übergeben.static final int STATUS_LOCK_KEYS
static final int STATUS_LOCK_KEYS_DONE
HBCIMsgStatus
)
als Zusatzinformation übergeben.static final int STATUS_INIT_SIGID
HBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
)
auftreten. Es werden keine Zusatzinformationen übergeben.static final int STATUS_INIT_SIGID_DONE
STATUS_INIT_SIGID
) eine Signatur-ID empfangen wurde. Als
Zusatzinformation wird ein Array übergeben, dessen erstes Element die Statusinformation
zu diesem Nachrichtenaustausch darstellt (HBCIMsgStatus
)
und dessen zweites Element die neue Signatur-ID (ein Long-Objekt) ist.static final int STATUS_DIALOG_INIT
static final int STATUS_DIALOG_INIT_DONE
HBCIMsgStatus
)
und dessen zweites Element die neue Dialog-ID ist.static final int STATUS_DIALOG_END
static final int STATUS_DIALOG_END_DONE
HBCIMsgStatus
)
als Zusatzinformation übergeben.static final int STATUS_MSG_CREATE
static final int STATUS_MSG_SIGN
static final int STATUS_MSG_CRYPT
static final int STATUS_MSG_SEND
passport
-Objekt immer null
). Wird aufgerufen,
wenn die erzeugte HBCI-Nachricht an den HBCI-Server versandt wird. Es werden
keine zusätzlichen Informationen übergeben.static final int STATUS_MSG_DECRYPT
static final int STATUS_MSG_VERIFY
static final int STATUS_MSG_RECV
passport
-Objekt immer null
). Wird aufgerufen, wenn
die Antwort-HBCI-Nachricht vom HBCI-Server empfangen wird. Es werden keine
zusätzlichen Informationen übergeben.static final int STATUS_MSG_PARSE
passport
-Objekt immer null
). Wird aufgerufen, wenn
HBCI4Java versucht, die empfangene Nachricht zu parsen. Es wird
der Name der erwarteten Nachricht als zusätzliche Information übergeben.static final int STATUS_SEND_INFOPOINT_DATA
static final int STATUS_MSG_RAW_SEND
STATUS_MSG_RAW_RECV
) die gesendeten und
empfangenen rohen HBCI-Nachrichten enthaelt. Sinnvoll zum Debuggen der Kommunikation
mit der Bank.static final int STATUS_MSG_RAW_RECV
STATUS_MSG_RAW_SEND
) die gesendeten und
empfangenen rohen HBCI-Nachrichten enthaelt. Sinnvoll zum Debuggen der Kommunikation
mit der Bank.void log(java.lang.String msg, int level, java.util.Date date, java.lang.StackTraceElement trace)
log(...)
an die Anwendung. Diese muss selbst
entscheiden, was mit der Information geschehen soll (einfach ignorieren,
abspeichern, dem Nutzer anzeigen, ...).msg
- die eigentliche Text-Meldung des HBCI-Kernelslevel
- Loglevel, welcher die "Wichtigkeit" dieser Meldung angibt. Die
möglichen Werte dafür sind in HBCIUtils
definiert und lauten
LOG_CHIPCARD
LOG_DEBUG
LOG_INFO
LOG_WARN
LOG_ERR
date
- Zeitpunkt, zu dem die Logausgabe generiert wurdetrace
- ein StackTrace
-Element, welches die Stelle
im Code beschreibt, an der die Logausgabe erzeugt wurde
(kann benutzt werden, um die Klasse, Methode, Zeilennummer etc.
des Aufrufes zu ermitteln)void callback(HBCIPassport passport, int reason, java.lang.String msg, int datatype, java.lang.StringBuffer retData)
reason
) übergeben, der anzeigt, welche Ursache
dieser Callbackaufruf hat, d.h. welche Daten oder Aktionen erwartet werden.
Falls Daten erwartet werden (z.B. ein Passwort, eine Benutzerkennung, ...),
so ist legt der Parameter datatype
fest, wie diese Daten erwartet
werden. Die eigentlichen Daten muss die Anwendung im Objekt retData
ablegen (keinen neuen StringBuffer erzeugen, sondern den Inhalt von retData
überschreiben!). Bei einigen Callbacks übergibt HBCI4Java einen vorgeschlagenen
default-Wert für die Nutzereingabe im retData-Objekt. Diese Tatsache ist
besonders bei der Auswertung des Callbacks HAVE_CRC_ERROR
zu beachten!passport
- enthält das Passport-Objekt, bei dessen Benutzung der
Callback erzeugt wurde. Falls also in einer Anwendung mehrere
Passport-Objekte gleichzeitig benutzt werden, so kann anhand
dieses Parameters festgestellt werden, welches Passport
(und damit welches HBCIHandle) HBCI4Java gerade benutzt.reason
- gibt den Grund für diesen Aufruf an. Dieser Parameter kann
alle Werte annehmen, die als "Ursache des Callback-Aufrufes" in der Dokumentation
aufgeführt sind. Je nach Wert dieses Parameters werden vom Nutzer
Aktionen oder Eingaben erwartet.msg
- ein Hinweistext, der den Grund des Callbacks näher beschreibt.
Dieser Parameter muss nicht ausgewertet werden, der Parameter
reason
ist bereits eindeutig. Er dient nur dazu,
bei Anwendungen, die nicht für jeden Ursache des Callback-Aufrufes einen eigenen
Hinweistext bereitstellen wollen, eine Art default-Wert für den
anzuzeigenden Text bereitzustellen.datatype
- legt fest, welchen Datentyp die vom HBCI-Kernel erwarteten
Antwortdaten haben müssen. Ist dieser Wert gleich
TYPE_NONE
, so werden keine Antwortdaten (also keine
Nutzereingabe) erwartet, bei TYPE_SECRET
und
TYPE_TEXT
wird ein normaler String erwartet.TYPE_SECRET
sensible Daten (Passwörter usw.) eingegeben
werden sollen, so dass die Eingaberoutine evtl. anders arbeiten
muss (z.B. Sternchen anstatt dem eingegebenen Text darstellen).retData
- In diesem StringBuffer-Objekt müssen die Antwortdaten
abgelegt werden. Beim Aufruf der Callback-Methode von HBCI4Java wird dieser
StringBuffer u.U. mit einem vorgeschlagenen default-Wert für die Nutzereingabe
gefüllt.void status(HBCIPassport passport, int statusTag, java.lang.Object[] o)
passport
- gibt an, welches Passport (und damit welches HBCIHandle)
benutzt wurde, als der Callback erzeugt wurde (siehe auch
callback(org.kapott.hbci.passport.HBCIPassport,int,String,int,StringBuffer)
).statusTag
- gibt an, welche Stufe der Abarbeitung gerade erreicht
wurde (alle oben beschriebenen Konstanten, die mit STATUS_
beginnen)o
- ein Array aus Objekten, das zusätzliche Informationen zum jeweiligen
Status enthält. In den meisten Fällen handelt es sich um einen
String, der zusätzliche Informationen im Klartext enthält. Welche Informationen
das jeweils sind, ist der Beschreibung zu den einzelnen STATUS_*
-Tag-Konstanten
zu entnehmen.void status(HBCIPassport passport, int statusTag, java.lang.Object o)
status(HBCIPassport, int, Object[])
für den Fall,
dass das Object[]
nur ein einziges Objekt enthältboolean useThreadedCallback(HBCIPassport passport, int reason, java.lang.String msg, int datatype, java.lang.StringBuffer retData)
Legt fest, ob ein Callback asynchron oder über den threaded-callback-Mechanismus
behandelt werden soll. Im "Normalfall" gibt diese Methode false
zurück, womit die asynchrone Callback-Behandlung aktiviert wird. Für
bestimmte Anwendungsfälle ist jedoch eine synchrone Callback-Behandlung
sinnvoll. Dazu muss zunächst das zu verwendende Callback-Objekt in einer
Instanz der Klasse HBCICallbackThreaded
gekapselt werden. Außerdem muss diese Methode so überschrieben werden,
dass sie für alle Callbacks, die synchron behandelt werden sollen,
true
zurückgibt.
Die übergebenen Parameter entsprechen denen der Methode
callback(HBCIPassport, int, String, int, StringBuffer)
. Der
Rückgabewert gibt ab, ob dieser Callback synchron (true
) oder
asynchron (false
) behandelt werden soll.
Mehr Informationen dazu in der Datei README.ThreadedCallbacks
.