hbci4java-help — all questions concerning hbci4java

Re: [Hbci4java-help] Hibiscus-Branch: Patch 13 (HHD_UC) und Patch 14 (HKTAN5, HHD1.4)

[Uwe F. <u....@gm...>]

Hallo,

ich lese auch mit und bin begeisterter Nutzer von dem Programm. 

Mein altes Konto mit "keyfile" bietet auch nicht diese
modernen Verfahren, von daher kann ich hier auch nichts testen...

Uwe

> hallo olaf,
> 
> 
> > PS: Bin ich hier eigentlich allein oder hat niemand sonst Interesse
> > an diesen neuen TAN-Verfahren? Hier antwortet gar keiner ;)
> 
> aber wir lesen aufmerksam ;-)
> 
> habe leider auch kein konto, mit dem ich dir testdaten generieren
> koennte...
> 
> besten dank auf jeden fall fuer dein engagement!
> 
> gruss
> 
> 
> max
> 
> Am 17.05.2011 19:21, schrieb Olaf Willuhn:
> > Hi,
> > 
> > Neue Patches. Nicht im Anhang, sondern als Links (die waren zu
> > gross ;))
> > 
> > 
> > Patch 12:
> > 
> > uebersprungen (hatte ich wieder rueckgaengig gemacht)
> > 
> > 
> > Patch 13:
> > http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/log/patches/13-hbci4java-hhd_uc.patch
> > 
> > Beruecksichtigt das DE "Challenge HHD_UC" aus der HITAN-Antwort (ab
> > Segment-Version 4) und reicht es im HBCI4Java-Callback
> > "NEED_PT_TAN" im Stringbuffer "retData" an die Anwendung weiter.
> > Damit kann die Anwendung prinzipiell den optischen Flickercode
> > erzeugen. Die Daten liegen aber noch im Rohformat vor.
> > 
> > In "Belegungsrichtlinien TANve1.4  mit Erratum 1-3 final version vom
> > 2010-11-12.pdf", Kapitel II.2 ist beschrieben, wie die Daten so
> > umgewandelt werden muessen, damit sie als blinkende Grafik angezeigt
> > werden koennen, wie in der Javascript-Beispiel-Implementierung unter
> > http://6xq.net/media/00/20/flickercode.html
> > 
> > Diese Umwandlung will ich noch direkt in HBCI4Java einbauen, damit
> > das die aufrufende Anwendung nicht selbst machen muss. Allerdings
> > brauch ich hier ein paar Spieldaten, die ich demnaechst hoffentlich
> > von Usern kriege.
> > 
> > Hinweis: Einige Banken (wohl auch die Sparkassen) senden den
> > Flicker-Code nicht in diesem DE "Challenge HHD_UC" sondern direkt
> > als Freitext im DE "Challenge". Das hat zwar den Vorteil, dass
> > optisches chipTAN dann zwar bereits ab HKTAN3 funktioniert. Man
> > muesste den Kram dann allerdings dort selbst rausfrickeln. Siehe
> > auch
> > http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?p=72214#72214
> > Fuer diese Variante gibt es keine Spezifikation. Vermutlich haben
> > die Sparkassen das einfach selbst da reingebaut, damit Starmoney es
> > als erstes kann ;) Sinnvoll implementierbar ist optisches chipTAN
> > also nur, wenn HKTAN4 oder 5 verwendet wird und der Code im dafuer
> > vorgesehenen "Challenge HHD_UC" uebertragen wird.
> > 
> > 
> > 
> > Patch 14:
> > http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/log/patches/14-hbci4java-hktan5-hhd14.patch
> > 
> > Das ist ein grosser Batzen ;)
> > Er erweitert die die Protokoll-Spezifikationen (hbci-*.xml) um
> > HKTAN/ HITAN/HITANS um Version 5. Die ist zwingend noetig, wenn man
> > HHD 1.4 (und damit optisches TAN machen will). Das Patch enthaelt
> > ausserdem Support fuer HHD 1.4. Ich musste hierzu
> > "challengedata.xml" und "ChallengeInfo.java" ziemlich umbauen. Und
> > ich konnte es selbst nicht testen, weil ich kein Konto habe,
> > welches diese neuen TAN-Versionen verwendet. Ich bin also auf
> > Rueckmeldungen gespannt ;)
> > 
> > 
> > PS: Bin ich hier eigentlich allein oder hat niemand sonst Interesse
> > an diesen neuen TAN-Verfahren? Hier antwortet gar keiner ;)
> > 
> > 
> > Gruss
> > Olaf
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Achieve unprecedented app performance and reliability
> > What every C/C++ and Fortran developer should know.
> > Learn how Intel has extended the reach of its next-generation tools
> > to help boost performance applications - inlcuding clusters.
> > http://p.sf.net/sfu/intel-dev2devmay
> > _______________________________________________
> > Hbci4java-help mailing list
> > Hbc...@li...
> > https://lists.sourceforge.net/lists/listinfo/hbci4java-help
> > 
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Hbci4java-help mailing list
> Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help

Re: [Hbci4java-help] Hibiscus-Branch: Patch 13 (HHD_UC) und Patch 14 (HKTAN5, HHD1.4)

[Max G. <max...@gm...>]

hallo olaf,


> PS: Bin ich hier eigentlich allein oder hat niemand sonst Interesse an
> diesen neuen TAN-Verfahren? Hier antwortet gar keiner ;)

aber wir lesen aufmerksam ;-)

habe leider auch kein konto, mit dem ich dir testdaten generieren koennte...

besten dank auf jeden fall fuer dein engagement!

gruss


max

Am 17.05.2011 19:21, schrieb Olaf Willuhn:
> Hi,
> 
> Neue Patches. Nicht im Anhang, sondern als Links (die waren zu gross ;))
> 
> 
> Patch 12:
> 
> uebersprungen (hatte ich wieder rueckgaengig gemacht)
> 
> 
> Patch 13:
> http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/log/patches/13-hbci4java-hhd_uc.patch
> 
> Beruecksichtigt das DE "Challenge HHD_UC" aus der HITAN-Antwort (ab
> Segment-Version 4) und reicht es im HBCI4Java-Callback "NEED_PT_TAN" im
> Stringbuffer "retData" an die Anwendung weiter. Damit kann die Anwendung
> prinzipiell den optischen Flickercode erzeugen. Die Daten liegen aber
> noch im Rohformat vor.
> 
> In "Belegungsrichtlinien TANve1.4  mit Erratum 1-3 final version vom
> 2010-11-12.pdf", Kapitel II.2 ist beschrieben, wie die Daten so
> umgewandelt werden muessen, damit sie als blinkende Grafik angezeigt
> werden koennen, wie in der Javascript-Beispiel-Implementierung unter
> http://6xq.net/media/00/20/flickercode.html
> 
> Diese Umwandlung will ich noch direkt in HBCI4Java einbauen, damit das
> die aufrufende Anwendung nicht selbst machen muss. Allerdings brauch ich
> hier ein paar Spieldaten, die ich demnaechst hoffentlich von Usern kriege.
> 
> Hinweis: Einige Banken (wohl auch die Sparkassen) senden den
> Flicker-Code nicht in diesem DE "Challenge HHD_UC" sondern direkt als
> Freitext im DE "Challenge". Das hat zwar den Vorteil, dass optisches
> chipTAN dann zwar bereits ab HKTAN3 funktioniert. Man muesste den Kram
> dann allerdings dort selbst rausfrickeln. Siehe auch
> http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?p=72214#72214
> Fuer diese Variante gibt es keine Spezifikation. Vermutlich haben die
> Sparkassen das einfach selbst da reingebaut, damit Starmoney es als
> erstes kann ;)
> Sinnvoll implementierbar ist optisches chipTAN also nur, wenn HKTAN4
> oder 5 verwendet wird und der Code im dafuer vorgesehenen "Challenge
> HHD_UC" uebertragen wird.
> 
> 
> 
> Patch 14:
> http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/log/patches/14-hbci4java-hktan5-hhd14.patch
> 
> Das ist ein grosser Batzen ;)
> Er erweitert die die Protokoll-Spezifikationen (hbci-*.xml) um HKTAN/
> HITAN/HITANS um Version 5. Die ist zwingend noetig, wenn man HHD 1.4
> (und damit optisches TAN machen will). Das Patch enthaelt ausserdem
> Support fuer HHD 1.4. Ich musste hierzu "challengedata.xml" und
> "ChallengeInfo.java" ziemlich umbauen. Und ich konnte es selbst nicht
> testen, weil ich kein Konto habe, welches diese neuen TAN-Versionen
> verwendet. Ich bin also auf Rueckmeldungen gespannt ;)
> 
> 
> PS: Bin ich hier eigentlich allein oder hat niemand sonst Interesse an
> diesen neuen TAN-Verfahren? Hier antwortet gar keiner ;)
> 
> 
> Gruss
> Olaf
> 
> 
> 
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Hbci4java-help mailing list
> Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help
> 

[Hbci4java-help] Hibiscus-Branch: Patch 13 (HHD_UC) und Patch 14 (HKTAN5, HHD1.4)

[Olaf W. <hbc...@wi...>]

Hi,

Neue Patches. Nicht im Anhang, sondern als Links (die waren zu gross ;))


Patch 12:

uebersprungen (hatte ich wieder rueckgaengig gemacht)


Patch 13:
http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/log/patches/13-hbci4java-hhd_uc.patch

Beruecksichtigt das DE "Challenge HHD_UC" aus der HITAN-Antwort (ab
Segment-Version 4) und reicht es im HBCI4Java-Callback "NEED_PT_TAN" im
Stringbuffer "retData" an die Anwendung weiter. Damit kann die Anwendung
prinzipiell den optischen Flickercode erzeugen. Die Daten liegen aber
noch im Rohformat vor.

In "Belegungsrichtlinien TANve1.4  mit Erratum 1-3 final version vom
2010-11-12.pdf", Kapitel II.2 ist beschrieben, wie die Daten so
umgewandelt werden muessen, damit sie als blinkende Grafik angezeigt
werden koennen, wie in der Javascript-Beispiel-Implementierung unter
http://6xq.net/media/00/20/flickercode.html

Diese Umwandlung will ich noch direkt in HBCI4Java einbauen, damit das
die aufrufende Anwendung nicht selbst machen muss. Allerdings brauch ich
hier ein paar Spieldaten, die ich demnaechst hoffentlich von Usern kriege.

Hinweis: Einige Banken (wohl auch die Sparkassen) senden den
Flicker-Code nicht in diesem DE "Challenge HHD_UC" sondern direkt als
Freitext im DE "Challenge". Das hat zwar den Vorteil, dass optisches
chipTAN dann zwar bereits ab HKTAN3 funktioniert. Man muesste den Kram
dann allerdings dort selbst rausfrickeln. Siehe auch
http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?p=72214#72214
Fuer diese Variante gibt es keine Spezifikation. Vermutlich haben die
Sparkassen das einfach selbst da reingebaut, damit Starmoney es als
erstes kann ;)
Sinnvoll implementierbar ist optisches chipTAN also nur, wenn HKTAN4
oder 5 verwendet wird und der Code im dafuer vorgesehenen "Challenge
HHD_UC" uebertragen wird.



Patch 14:
http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/log/patches/14-hbci4java-hktan5-hhd14.patch

Das ist ein grosser Batzen ;)
Er erweitert die die Protokoll-Spezifikationen (hbci-*.xml) um HKTAN/
HITAN/HITANS um Version 5. Die ist zwingend noetig, wenn man HHD 1.4
(und damit optisches TAN machen will). Das Patch enthaelt ausserdem
Support fuer HHD 1.4. Ich musste hierzu "challengedata.xml" und
"ChallengeInfo.java" ziemlich umbauen. Und ich konnte es selbst nicht
testen, weil ich kein Konto habe, welches diese neuen TAN-Versionen
verwendet. Ich bin also auf Rueckmeldungen gespannt ;)


PS: Bin ich hier eigentlich allein oder hat niemand sonst Interesse an
diesen neuen TAN-Verfahren? Hier antwortet gar keiner ;)


Gruss
Olaf

[Hbci4java-help] Hibiscus-Branch: Patch 11 fuer mehrere TAN-Verfahren mit gleicher Sicherheitsfunktion

[Olaf W. <hbc...@wi...>]

Hi,

Noch ein Patch, welches durch Rueckmeldungen auf
https://www.willuhn.de/bugzilla/show_bug.cgi?id=827
entstanden ist.

Eine Bank kann ein TAN-Verfahren mit gleicher Sicherheitsfunktion (diese
3-stellige Nummer, die mit 9 beginnt) mehrfach in verschiedenen
HITANS-Segmenten der BPD melden. HBCi4Java hat die bisher dann einfach
ueberschrieben und so ggf. aus Versehen das TAN-Verfahren aus der alten
Segment-Version verwendet. Das angehaengte Patch sorgt dafuer, dass dies
nicht mehr geschieht. Ist ein TAN-Verfahren mehrmals vorhanden, wird das
aus der hoechsten Segment-Version verwendet.

Im Fall des betroffenen Users gab es ein smsTAN-Verfahren mit gleicher
Nummer zweimal. Einmal in HITANS1 und einmal in HITANS3. Nur bei dem in
HITANS3 ist die Abfrage der Medienbezeichnung erforderlich. Das HKTAN
wurde in Version 3 erzeugt, jedoch mit dem smsTAN aus HITANS1. Effekt:
Abfrage der Medienbezeichnung erfolge nicht, obwohl eigentlich notwendig.

Gruss
Olaf

Re: [Hbci4java-help] HBCI4Java "Hibiscus-Branch" fuer smsTAN/chipTAN

[Olaf W. <hbc...@wi...>]

Hi,

ich habs scheinbar hingekriegt ;)
In https://www.willuhn.de/bugzilla/show_bug.cgi?id=827 meldete mir ein
User gerade, dass es funktionierte (also der Callback mit der Rueckfrage
der Medienbezeichnung fuer die SMS-TAN).

http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/log/patches/10-hbci4java-tanmedia.patch

Ist ab sofort auch im Nightly-Build von Hibiscus.

Gruss
Olaf

Re: [Hbci4java-help] HBCI4Java "Hibiscus-Branch" fuer smsTAN/chipTAN

[Olaf W. <hbc...@wi...>]

Hi,

> Im ersten Schritt will ich versuchen, die Unterstuetzung fuer die
> smsTAN-Medienbezeichnung einzubauen, das scheint mir noch der am
> wenigsten aufwaendige Teil zu sein.

Ich glaube, ich hatte gerade einen Anflug von Verstaendnis ueber die
HBCI4Java-Interna und meine, die Sache kapiert zu haben. Im Anhang ein
Patch, welches:

1) in GVTAN2Step.java einen Parameter hinzufuegt:

   addConstraint("tanmedia", "tanmedia","", LogFilter.FILTER_IDS);

2) in HBCICallback.java einen neuen Callback definiert:

   public final static int NEED_PT_TANMEDIA=32;

3) in AbstractPinTanPassport ermittelt, ob die Angabe des TAN-Mediums
   erforderlich ist, den Callback ausloest und den Parameter zum
   HBCJob hinzufuegt, etwa so:

   if (hktan_version >= 3) {
     // Anzahl aktiver TAN-Medien ermitteln
     int num = Integer.parseInt(secmechInfo.getProperty("nofactivetanmedia","0"));
     boolean needed = secmechInfo.getProperty("needtanmedia","").equals("2");
     if (num > 1 && needed) {
       StringBuffer retData=new StringBuffer();
       HBCIUtilsInternal.getCallback().callback(this,HBCICallback.NEED_PT_TANMEDIA,
         "*** Enter the name of your TAN media",
         HBCICallback.TYPE_TEXT,
         retData);
       String  value = retData.toString();
       hktan.setParam("tanmedia",value);
     }
   }

Siehe Patch im Anhang.

Sieht das plausibel aus? Koennte das funktionieren?
Hab ich was vergessen?

Gruss
Olaf

[Hbci4java-help] HBCI4Java "Hibiscus-Branch" fuer smsTAN/chipTAN

[Olaf W. <hbc...@wi...>]

Hallo Liste,

inzwischen ist ja absehbar, dass so ziemlich alle Banken ihre
TAN-Verfahren in den naechsten 1-2 Monaten auf smsTAN/chipTAN umstellen
werden oder bereits umgestellt haben. Im aktuellen HBCI4Java 2.5.12
werden sie noch nicht vollstaendig unterstuetzt.

 - smsTAN nur ohne Medienbezeichnung
 - chipTAN nur manuell

Ausserdem fehlt noch HHD 1.4 (welches die Postbank meines Wissens nach
bereits verwendet, wodurch dort auch chipTAN manuell nicht funktioniert)

Alles in allem sieht es dann in HBCI4Java mit der PIN/TAN-Unterstuetzung
ziemlich truebe aus. Leider ist ausgerechnet dieses Verfahren auch noch
das am weitesten verbreitete.

Da Stefan ja mit HBCI4Java 3 beschaeftigt ist, habe ich im Hibiscus-CVS
meinen aktuellen 2.5.12er Snapshot von HBCI4Java eingecheckt (konkret
ist das r227 + eine Hand voll Patches) und will versuchen, dort die
noetigsten Sachen nachzuruesten.

http://cvs.berlios.de/cgi-bin/viewvc.cgi/hibiscus/hbci4java/

@Stefan: Ich hoffe, du hast kein Problem damit ;)


Im ersten Schritt will ich versuchen, die Unterstuetzung fuer die
smsTAN-Medienbezeichnung einzubauen, das scheint mir noch der am
wenigsten aufwaendige Teil zu sein.

  - In hbci-${version.xml scheint es (bei hhd 1.2 und 1.3) schon
    drin zu stehen (Parameter "tanmedia")
  - in GVTAN2Step.java, Zeile 70 steht schon ein TODO
  - in AbstractPinTanPassport.java, Zeile 962 muesste noch hhd 1.4
    beruecksichtigt werden (das aber spaeter)
  - in AbstractPinTanPassport.java, ab Zeile 1034 muesste ich
    wahrscheinlich den Callback mit der User-Abfrage fuer die
    Handy-Bezeichnung (erstmal Freitext, keine Auswahlbox) reinbauen.
    Wobei ich hier noch nicht weiss, wie ich erkennen kann, ob der
    Callback noetig ist oder nicht (vermutlich in
    GVTAN2Step#extractResults schauen, ob "needtanmedia" gesetzt ist).

Wenn ich das hinkriege, will ich versuchen, hhd 1.4 nachzuruesten. Dann
habe ich mich hoffentlich weit genug eingearbeitet, um mich an optisches
chipTAN zu wagen.


Ein echtes Testkonto hab ich zwar nicht. Aber meine Sparkasse bietet
beide TAN-Verfahren an. Werde naechste Woche mal zur Filiale fahren und
das freischalten lassen, damit ich testen kann.


Lange Rede, kurzer Sinn. Wenn ihr Code-Schnippsel oder Patches fuer
HBCI4Java 2.5.12 habt, die mit dem Thema zu tun haben oder anderweitig
helfen koennt und wollt, wuerde ich mich ueber Unterstuetzung freuen.
Mir helfen sicher auch schon ganz allgemeine Hinweise wie: "Schau mal in
Klasse XY, dort muesste das stehen".

Gruss
Olaf

Re: [Hbci4java-help] (no subject)

[HBCI4Java (S. Palme) <hbc...@ka...>]

Hallo,

> Meine Bank lässt beispielsweise nur iTan zu. Der Konsolendialog zum
> erstellen eines neuen Passports nimmt aber automatisch "999" an

Beim allerersten Verbindungsaufbau zur Bank (der anonym, also ohne
Verwendung eines bestimmten PIN/TAN-Verfahrens passiert), holt sich
HBCI4Java u.a. die Liste der unterstützten Verfahren ab. In der Regel
steht dort sowohl "999" (das alte PIN/TAN-Verfahren) als auch irgend ein
anderes (iTAN, mTAN, chipTAN, ...) drin.

Später wird ermittelt, welche der von der Bank PRINZIPIELL unterstützten
Verfahren tatsächlich für Deine Nutzerkennung freigeschaltet sind (meine
Bank unterstützt z.B. u.a. iTAN und mTAN, für meinen eigenen Account ist
aber nur iTAN freigeschaltet).

Das ganze ist ein Henne-Ei-Problem, und HBCI4Java versucht hier durch
"raten" bzw. "Nochmal-Probieren-bei-Fehler" eine möglichst schmerzfreie
Entscheidung zu treffen.

Könntest Du mir evtl. ein Logfile (Loglevel "5") schicken, damit ich
sehe, an welcher Stelle die falsche Entscheidung getroffen wird? (Mail
am besten persönlich an hbc...@ka..., nicht an die Liste)


> Gibt es einen Setter für den Wert

  ((HBCIPassportPinTan)passport).setCurrentTANMethod("991");

Das gehört allerdings NICHT ZUM OFFIZIELLEN API... Der richtige Ansatz
zur Lösung des Problems ist auf jeden Fall herauszufinden, warum
HBCI4Java ohne Rückfrage "999" verwendet, obwohl angeblich auch noch
andere Mechanismen unterstützt werden.

Gruß
-stefan-


On Wed, 2010-12-15 at 16:07 +0100, Florian Engel wrote:
> Hallo !
> ich sitze gerade an meiner Semesterarbeit, für die ich auch HBCI4Java nutze. 
> Ich bin so gut wie fertig, leider schaffe ich es jedoch nicht, die Einstellung 
> für das PIN/Tan Verfahren zu ändern. Meine Bank lässt beispielsweise nur iTan 
> zu. Der Konsolendialog zum erstellen eines neuen Passports nimmt aber 
> automatisch "999" an, woraufhin meine Bank die Verbindung abbricht. Gibt es 
> einen Setter für den Wert ? Bzw. kann ich die Option vielleicht im Dialog 
> ergänzen ?
> 
> Mit freundlichen Grüßen
> Florian Engel

-- 
Stefan Palme
hbc...@ka...
+49 178 3227887

[Hbci4java-help] (no subject)

[Florian E. <vip...@gm...>]

Hallo !
ich sitze gerade an meiner Semesterarbeit, für die ich auch HBCI4Java nutze. 
Ich bin so gut wie fertig, leider schaffe ich es jedoch nicht, die Einstellung 
für das PIN/Tan Verfahren zu ändern. Meine Bank lässt beispielsweise nur iTan 
zu. Der Konsolendialog zum erstellen eines neuen Passports nimmt aber 
automatisch "999" an, woraufhin meine Bank die Verbindung abbricht. Gibt es 
einen Setter für den Wert ? Bzw. kann ich die Option vielleicht im Dialog 
ergänzen ?

Mit freundlichen Grüßen
Florian Engel
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

Re: [Hbci4java-help] Commerzbank Saldoabfrage

[Marcus W. <Ma...@Wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ich benutze seid Jahren die Comdirect Bank mit HBCI4java mit jGnucashlib.


"Olaf Willuhn" <hbc...@wi...> schrieb:

>> Die Hotline der Commerzbank hätte behauptet, dieses Problem sei
>bekannt,
>> träte allerdings nur bei Hibiscus/HBCI4Java auf - das hätte mit
>dieser
>> Software angeblich NOCH NIE(!) funktioniert.
>
>Das glaub ich nicht.
>
>> Bevor ich mich zu weit aus dem Fenster lehne: kann das jemand
>> bestätigen / dementieren? Ich kann mir grad nicht vorstellen, dass
>alle
>> Commerzbank-Kunden *schon immer* das Problem haben, dass Umsatz- plus
>> Saldoabruf nicht funktionieren, und dass mir das noch keiner gesagt
>> hat :-)
>
>Aktuell findet sich im Online-Banking einer mit dem gleichen
>Problem (vielleicht ist das auch der selbe User):
>
>http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?t=12230
>
>Und unter
>http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?t=10760
>hatte einer ebenfalls das Problem - und eine Loesung gefunden:
>
>a) die Kontonummer auf 10 Stellen (links mit einer Null aufgefuellt)
>und
>b) HBCI Version auf 2.1 umgestellt
>
>
>Vielleicht hilft das ja.
>
>Gruss
>Olaf
>
>------------------------------------------------------------------------------
>Start uncovering the many advantages of virtual appliances
>and start using them to simplify application deployment and
>accelerate your shift to cloud computing.
>http://p.sf.net/sfu/novell-sfdev2dev
>_______________________________________________
>Hbci4java-help mailing list
>Hbc...@li...
>https://lists.sourceforge.net/lists/listinfo/hbci4java-help
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.7

iI0EAREIAE0FAkyjT0RGHE1hcmN1cyBXb2xzY2hvbiAoZW1haWwtYWRyZXNzIGZv
ciBidXNpbmVzcy11c2UpIDxNYXJjdXNAV29sc2Nob24uYml6PgAKCRA1p5EQQT42
dmpMAJ49FnR0FDGlnL8HjZlu+7RFec7wtgCgjcTPgJeWS7MYTo7amkp7ENgPsF8=
=TMKP
-----END PGP SIGNATURE-----

Re: [Hbci4java-help] Commerzbank Saldoabfrage

[Olaf W. <hbc...@wi...>]

> Die Hotline der Commerzbank hätte behauptet, dieses Problem sei bekannt,
> träte allerdings nur bei Hibiscus/HBCI4Java auf - das hätte mit dieser
> Software angeblich NOCH NIE(!) funktioniert.

Das glaub ich nicht.

> Bevor ich mich zu weit aus dem Fenster lehne: kann das jemand
> bestätigen / dementieren? Ich kann mir grad nicht vorstellen, dass alle
> Commerzbank-Kunden *schon immer* das Problem haben, dass Umsatz- plus
> Saldoabruf nicht funktionieren, und dass mir das noch keiner gesagt
> hat :-)

Aktuell findet sich im Online-Banking einer mit dem gleichen
Problem (vielleicht ist das auch der selbe User):

http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?t=12230

Und unter
http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?t=10760
hatte einer ebenfalls das Problem - und eine Loesung gefunden:

a) die Kontonummer auf 10 Stellen (links mit einer Null aufgefuellt) und
b) HBCI Version auf 2.1 umgestellt


Vielleicht hilft das ja.

Gruss
Olaf

[Hbci4java-help] Commerzbank Saldoabfrage

[HBCI4Java (S. Palme) <hbc...@ka...>]

Hallo,

habe hier gerade einen Nutzer, der Probleme damit hat, bei der
Commerzbank eine Umsatzabfrage, gefolgt von einer Saldoabfrage zu machen
(Umsatzabfrage klappt, Saldoabfrage ergibt "Keine gültige
Kontoverbindung des Kunden").

Die Hotline der Commerzbank hätte behauptet, dieses Problem sei bekannt,
träte allerdings nur bei Hibiscus/HBCI4Java auf - das hätte mit dieser
Software angeblich NOCH NIE(!) funktioniert.

Bevor ich mich zu weit aus dem Fenster lehne: kann das jemand
bestätigen / dementieren? Ich kann mir grad nicht vorstellen, dass alle
Commerzbank-Kunden *schon immer* das Problem haben, dass Umsatz- plus
Saldoabruf nicht funktionieren, und dass mir das noch keiner gesagt
hat :-)

Danke und Gruß!
-stefan-

-- 
Stefan Palme
hbc...@ka...
+49 178 3227887

Re: [Hbci4java-help] Optisches chipTAN

[Olaf W. <hbc...@wi...>]

Hi,

Status-Update:

ich habe von Reiner SCT einen optischen TAN-Generator
als Leihgeraet zum Testen erhalten. Prima.

Unter
https://www.sparkasse-freiburg.de/onlinebanking/demoanwendung/index.php
gibts eine Onlinebanking-Demo, bei der man auch chipTAN verwenden
kann. Das funktioniert natuerlich. Um mal zu schauen, wie die das
in der Webseite gemacht haben, hab ich mir den HTML- und JS-Quellcode
mal angeschaut. Die haben da 3 verschiedene Varianten von Flicker-
Code-Renderern. Einen mit Flash, einen mit der schwarze und weisse
GIFs tauscht und einen, der mit Canvas arbeitet. Dort fand ich auch
den Flickercode, der bei meinem Test gerendert wurde:

100484652456044356435F14312C30304B

Jetzt kommts: Mit meiner Test-Implementierung "ChipTanFlickerCode",
die das auf SWT rendert, konnte ich den Code tatsaechlich an
den TAN-Generator uebertragen (ich hatte vorher lediglich schwarz
und weiss falsch rum belegt)!

Prima, dachte ich. Geschafft.

Leider doch noch nicht. Der auf
http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?p=60532
angezeigte Code

002624088715131306389726041,00

laesst sich nicht rendern. Das ist das, was in dem TAN-Dialog
zwischen "CHLGUC" und "CHLGTEXT" angezeigt wird. Offensichtlich
handelt es sich hier noch nicht um einen renderfaehigen Flickercode.
Stattdessen muss er wohl noch umgewandelt, erweitert oder irgendwie
anderweitig konvertiert werden, damit er angezeigt werden kann.

Und hier stecke ich fest: Ich habe
http://www.hbci-zka.de/dokumente/spezifikation_deutsch/Belegungsrichtlinien%20TAN-Generator%20ve1.4%202010-07-23%20mit%20Erratum%201%20final%20version%20.pdf

durchforstet, finde dazu aber keine Informationen.

Weiss irgend jemand, wie man diesen Text zwischen "CHLGUC" und
"CHLGTEXT" in einen renderfaehigen Code wandeln kann?

@Martin: Liest du hier mit? Hast du das in AqBanking vielleicht
schon umgesetzt?

Gruss
Olaf

Re: [Hbci4java-help] Optisches chipTAN

[Olaf W. <hbc...@wi...>]

Hi,

>> 1) Der Flicker-Code ist ja eine lange Zahlenkolonne, die
[...]
>>    Der relevante Code ist wohl alles zwischen "CHLGUC" und
>>    "CHLGTEXT". Ich hab zwar keine Ahnung, ob ich mich auf
>>    die Anwesenheit dieser beiden Tokens verlassen. Da ich
>>    aber noch einen zweiten Screenshot von einem TAN-Dialog
>>    aus Hibiscus habe, in dem die gleichen Tokens verwendet
>>    werden, wuerde ich die erstmal als Erkennung verwenden.
> 
> Ist das eine Frage? ;-)

Ja, irgendwie schon ;)
Ich hatte gehofft, dass jemand schreibt: "Ja, kannste
erstmal so machen." oder "Ne, geht leider nicht."

Allerdings bin ich mit der Weiterentwicklung inzwischen
ziemlich ins Stocken geraten, weil ein Bekannter (der
einen solchen TAN-Generator hat) keine einzige der
von mir erzeugten Flickercodes scannen konnte. Irgendwas
mache ich da offensichtlich noch grundsaetzlich falsch.
Ich weiss nur nicht was. Und ohne eigenes Testgeraet
kommt man dem auch nur schlecht auf die Spur.

>> 2) Woher weiss ich, ob ueberhaupt optisches ChipTAN verwendet
>>    wird? Die Informationen brauche ich ja, um entscheiden
>>    zu koennen, ob ich dem User den Plaintext-TAN-Dialog
>>    anzeige oder den mit der Flicker-Grafik.
> 
> Soweit ich weiß, steht das in den BPD. Ab HITANS-4 gibt es ein
> Datenelement "ZKA-TAN-Verfahren", in welchem die Art des Verfahrens
> kodiert wird (HHD, HHDUC, ...). Ich glaube, anhand dieses Feldes kann
> man das sauber unterscheiden.
> 
> Derzeit gibt es in HBCI4Java allerdings kein schönes API, um diesen Wert
> abzufragen.

Das klingt doch schonmal gar nicht schlecht. Da ich die BPD/UPD
in Hibiscus eh direkt in der Datenbank cache, kann ich die
eigentlich auch verhaeltnismaessig bequem durchsuchen.

>>    Die TAN-Verfahren haben ja diese 3-stelligen Nummern 9xx.
>>    Bisher war ich der Meinung, dass diese Nummern nicht
>>    bankuebergreifend einheitlich fuer die Verfahren vergeben
>>    werden. Oder ist dem doch so?
> 
> Die Nummern sind nicht vereinheitlicht.

Schade. Das hatte ich befuerchtet.

>> 3) Kann mein erzeugter Flicker-Code von einem echten
>>    Geraet ueberhaupt gelesen werden? Ich hab selbst kein
>>    Testgeraet.
> 
> Das weiß ich auch nicht. Die schleppende Entwicklung in HBCI4Java ist
> derzeit u.a. dem Fakt geschuldet, dass ich selbst keine
> Testmöglichkeiten habe. Die Banken sind in dieser Beziehung sehr geizig
> und wenig hilfsbereit. 

Ich koennte mal Hylli von der VR Krautheim fragen. Vielleicht
kann er ja sowas besorgen. Oder jemand anderes aus dem
Onlinebanking-Forum. Allerdings weiss ich gar nicht, ob man
zum Testen einen x-beliebigen TAN-Generator nehmen kann oder
ob das nur funktioniert, wenn man auch wirklich einen
entsprechenden Bank-Zugang hat.

Gruss
Olaf

Re: [Hbci4java-help] Optisches chipTAN

[HBCI4Java (S. Palme) <hbc...@ka...>]

Hi,

On Fri, 2010-09-03 at 01:04 +0200, Olaf Willuhn wrote:
> Eigentlich hatte ich bisher nicht den geringsten Schimmer, wie
> ich dieses optische ChipTAN (mit dem Flickercode auf dem Bildschirm)
> in Hibiscus umsetzen koennte. Allerdings bin ich inzwischen auf
> diese Seite gestossen:
> 
> http://6xq.net/media/00/20/flickercode.html
> 
> Das ist eine Implementierung in Javascript, welche den Code
> mittels HTML/Canvas zeichnet.
> 
> Ich hab das jetzt so ziemlich 1:1 nach Java portiert und
> zeichne den Code stattdessen mit SWT/Canvas. War gar nicht
> so viel Aufwand, wie ich dachte.
> 
> Jetzt bleiben noch 3 Fragen offen:
> 
> 1) Der Flicker-Code ist ja eine lange Zahlenkolonne, die
>    offensichtlich direkt in den 'human-readable' Fliesstext
>    der TAN-Abfrage eingebettet ist. Hier ist mal ein
>    Screenshot, wie das aussieht, wenn die Software optisches
>    chipTAN noch nicht kann und das daher im Plaintext
>    anzeigt:
>    http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?t=10697
>    Der relevante Code ist wohl alles zwischen "CHLGUC" und
>    "CHLGTEXT". Ich hab zwar keine Ahnung, ob ich mich auf
>    die Anwesenheit dieser beiden Tokens verlassen. Da ich
>    aber noch einen zweiten Screenshot von einem TAN-Dialog
>    aus Hibiscus habe, in dem die gleichen Tokens verwendet
>    werden, wuerde ich die erstmal als Erkennung verwenden.

Ist das eine Frage? ;-)

Zum Format der Flickergrafik-Codes kann ich derzeit auch nichts weiter
sagen, muss mir dazu erst mal die entsprechenden Dokumentationen
besorgen. 

> 2) Woher weiss ich, ob ueberhaupt optisches ChipTAN verwendet
>    wird? Die Informationen brauche ich ja, um entscheiden
>    zu koennen, ob ich dem User den Plaintext-TAN-Dialog
>    anzeige oder den mit der Flicker-Grafik.

Soweit ich weiß, steht das in den BPD. Ab HITANS-4 gibt es ein
Datenelement "ZKA-TAN-Verfahren", in welchem die Art des Verfahrens
kodiert wird (HHD, HHDUC, ...). Ich glaube, anhand dieses Feldes kann
man das sauber unterscheiden.

Derzeit gibt es in HBCI4Java allerdings kein schönes API, um diesen Wert
abzufragen.

>    Die TAN-Verfahren haben ja diese 3-stelligen Nummern 9xx.
>    Bisher war ich der Meinung, dass diese Nummern nicht
>    bankuebergreifend einheitlich fuer die Verfahren vergeben
>    werden. Oder ist dem doch so?

Die Nummern sind nicht vereinheitlicht.

>  Also koennte ich mich
>    beispielsweise drauf verlassen, dass 922 optisches chipTAN
>    ist?

Nein.

>    Falls nicht, koennte ich in der TAN-Abfrage schauen,
>    ob die beiden Token auftauchen und dann einfach annehmen,
>    dass das wohl optisches chipTAN sein wird.

Das wäre wahrscheinlich ein erster Workaround, aber wie gesagt, ich bin
mir einigermaßen sicher, dass die entsprechenden Informationen in den
BPD zu finden sein sollten.

> 3) Kann mein erzeugter Flicker-Code von einem echten
>    Geraet ueberhaupt gelesen werden? Ich hab selbst kein
>    Testgeraet.

Das weiß ich auch nicht. Die schleppende Entwicklung in HBCI4Java ist
derzeit u.a. dem Fakt geschuldet, dass ich selbst keine
Testmöglichkeiten habe. Die Banken sind in dieser Beziehung sehr geizig
und wenig hilfsbereit. 


Gruß
-stefan-


-- 
Stefan Palme
hbc...@ka...

[Hbci4java-help] Optisches chipTAN

[Olaf W. <hbc...@wi...>]

Hi,

jaja, ich weiss. Diese unsaeglichen TAN-Verfahren ;)
Eigentlich hatte ich bisher nicht den geringsten Schimmer, wie
ich dieses optische ChipTAN (mit dem Flickercode auf dem Bildschirm)
in Hibiscus umsetzen koennte. Allerdings bin ich inzwischen auf
diese Seite gestossen:

http://6xq.net/media/00/20/flickercode.html

Das ist eine Implementierung in Javascript, welche den Code
mittels HTML/Canvas zeichnet.

Ich hab das jetzt so ziemlich 1:1 nach Java portiert und
zeichne den Code stattdessen mit SWT/Canvas. War gar nicht
so viel Aufwand, wie ich dachte.

Jetzt bleiben noch 3 Fragen offen:

1) Der Flicker-Code ist ja eine lange Zahlenkolonne, die
   offensichtlich direkt in den 'human-readable' Fliesstext
   der TAN-Abfrage eingebettet ist. Hier ist mal ein
   Screenshot, wie das aussieht, wenn die Software optisches
   chipTAN noch nicht kann und das daher im Plaintext
   anzeigt:
   http://www.onlinebanking-forum.de/phpBB2/viewtopic.php?t=10697
   Der relevante Code ist wohl alles zwischen "CHLGUC" und
   "CHLGTEXT". Ich hab zwar keine Ahnung, ob ich mich auf
   die Anwesenheit dieser beiden Tokens verlassen. Da ich
   aber noch einen zweiten Screenshot von einem TAN-Dialog
   aus Hibiscus habe, in dem die gleichen Tokens verwendet
   werden, wuerde ich die erstmal als Erkennung verwenden.

2) Woher weiss ich, ob ueberhaupt optisches ChipTAN verwendet
   wird? Die Informationen brauche ich ja, um entscheiden
   zu koennen, ob ich dem User den Plaintext-TAN-Dialog
   anzeige oder den mit der Flicker-Grafik.
   Die TAN-Verfahren haben ja diese 3-stelligen Nummern 9xx.
   Bisher war ich der Meinung, dass diese Nummern nicht
   bankuebergreifend einheitlich fuer die Verfahren vergeben
   werden. Oder ist dem doch so? Also koennte ich mich
   beispielsweise drauf verlassen, dass 922 optisches chipTAN
   ist?
   Falls nicht, koennte ich in der TAN-Abfrage schauen,
   ob die beiden Token auftauchen und dann einfach annehmen,
   dass das wohl optisches chipTAN sein wird.

3) Kann mein erzeugter Flicker-Code von einem echten
   Geraet ueberhaupt gelesen werden? Ich hab selbst kein
   Testgeraet.

Ich hab den Code als Test daher mal eingecheckt. Wer es ausprobieren
will:

wget http://www.willuhn.de/products/hibiscus/releases/nightly/hibiscus-1.12.0-nightly.zip
wget http://ftp.wh2.tu-dresden.de/pub/mirrors/eclipse/eclipse/downloads/drops/R-3.6-201006080911/swt-3.6-gtk-linux-x86.zip
unzip hibiscus-1.12.0-nightly.zip
unzip swt-3.6-gtk-linux-x86.zip
java -cp swt.jar:hibiscus/hibiscus.jar de.willuhn.jameica.hbci.gui.parts.ChipTanFlickerCode

Code eingeben und "Start" druecken. Der Flickercode muss wohl
angeblich so skaliert werden, dass er genauso breit wie
die Scanner-Einheit am chipTAN-Geraet ist. Dazu kann man
das Fenster einfach vergroessern/verkleinern.

Ich wuerd mich freuen, wenn jemand Antworten zu meinen Fragen hat
oder mal den Test-Code ausprobieren koennte.

Gruss
Olaf

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[HBCI4Java (S. Palme) <hbc...@ka...>]

On Tue, 2010-08-31 at 17:22 +0200, Olaf Willuhn wrote:
> Oh ja, eine generische Bank-API in Java. Davon traeume ich auch
> schon lange. Ich war schon mehrmals kurz davor, sowas anzufangen.
> Aber die Bank-Systeme (schon allein die Einrichtung eines Accounts)
> sind so verschieden, dass ich mich da noch nicht rangetraut habe.
> Vielleicht sollte ich mir mal den AqBanking-Source anschauen und
> mir da Ideen holen. ;)

Ich hatte mal im Rahmen eines anderen Projektes ein generisches
Payment-Framework gebaut, das u.a. Bezahlen via HBCI (Überweisung /
Lastschrift), PayPal, Geldkarte, Kreditkarte und diversen webbasierten
Verfahren ermöglicht hat. War zwar eher ein "akademisches" Projekt, weil
das ganze so lief, dass ein "Shop" ein bestimmtes generisches API
implementieren musste, um dieses System nutzen zu können - aber
funktioniert hat es :-)

Vllt. sollte ich das mal wieder rauskramen und da nochmal einen
"abstrakten Blick" draufwerfen...

Heute jedoch nicht mehr :-)

Gruß!
-stefan-

-- 
Stefan Palme
hbc...@ka...

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[Olaf W. <hbc...@wi...>]

HBCI4Java (Stefan Palme) wrote:

> Das von Dir vorgeschlagene "Callback-Feature" halte ich prinzipiell
> ebenfalls für sinnvoll - allerdings nicht in HBCI4Java. Vielleicht hat
> ja mal jemand Lust auf ein OnlineBanking4Java - HBCI4Java könnte dabei
> ein Bestandteil für die "Kommunikation mit der Bank via HBCI" sein...

Oh ja, eine generische Bank-API in Java. Davon traeume ich auch
schon lange. Ich war schon mehrmals kurz davor, sowas anzufangen.
Aber die Bank-Systeme (schon allein die Einrichtung eines Accounts)
sind so verschieden, dass ich mich da noch nicht rangetraut habe.
Vielleicht sollte ich mir mal den AqBanking-Source anschauen und
mir da Ideen holen. ;)

Grus
Olaf

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[Olaf W. <hbc...@wi...>]

Hi,

> Hmm... Eventuell verzichte ich auch einfach darauf, die BPD mitzusenden
> - die könnte der InfoPoint-Server schließlich mit Hilfe der angeblich
> funktionierenden Zugangsdaten auch selbst abholen...
> 
> Dann wäre jedenfalls die Datenmenge, die versendet werden soll und die
> der Nutzer nochmal zu sehen bekommen sollte, schon sehr viel geringer
> und übersichtlicher...

Faend ich ne gute Idee. Vielleicht wuerden in einem ersten Schritt
schon BLZ, URL, HBCI-Version und TAN-Verfahren (wenn das geht) reichen.

Gruss
Olaf

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[HBCI4Java (S. Palme) <hbc...@ka...>]

Hallo Martin,

On Tue, 2010-08-31 at 15:58 +0200, Martin Honermeyer wrote:
> Offensichtlich habe ich hier einen anderen (kommerziellen) Anwendungsfall als 
> die meisten Nutzer der Bibliothek. Wir speichern (in-house) die Kontodaten von 
> Kunden, um regelmäßige Lastschriften durchführen zu können. Die Daten werden 
> von den Kunden selbst eingegeben und ich prüfe sie bei der Eingabe mit Hilfe 
> von HBCI4Java (getNameForBLZ, checkAccountCRC). Im gleichen Schritt trage ich 
> die Daten der Bank (BIC, Prüfalgorithmus) mit Hilfe von HBCI4Java in die 
> Datenbank meiner Anwendung ein, um schnell darauf zugreifen und alte Banken 
> als nicht mehr gültig markieren zu können.
> 
> Durch ein Update meiner Bankenliste wollte ich
> 
> * nicht mehr gültige Konten finden und aktualisieren bzw. löschen und die 
> Kunden entsprechend informieren
> * Kunden ermöglichen, Konten mit neuen, bisher unbekannten Bankleitzahlen 
> angeben zu können, ohne dass die Prüfung sie ablehnt.

Verstehe. Aber wie gesagt - aus meiner Sicht ist das keine Aufgabe, die
eine HBCI-Bibliothek erledigen sollte (schon rein konzeptionell). 

Zum einen könnte Deine Anwendung theoretisch ja parallel zu HBCI auch
auf anderem Wege mit Bankkonten arbeiten (EBICS, ScreenScraping, ...) -
in WELCHER der entsprechenden Bibliotheken sollte denn dann die von Dir
vorgeschlagene Logik für die Bankenliste implementiert werden? In allen?

Davon abgesehen gibt es schon Bibliotheken, die sich speziell dem Thema
Kontonummern-Überprüfung widmen (z.B. ktoblzcheck). Dort wäre ein
solches Feature wesentlich besser aufgehoben.

Ich will einfach vermeiden, dass ich HBCI4Java mit Code aufblähe, der
eigentlich nichts mehr mit HBCI zu tun hat, sondern auf eine viel
höhere, abstraktere Ebene gehört.

> Ich kenne z.B. Hibiscus nicht so genau, aber kann der Nutzer dort nicht auch 
> Empfängerkonten speichern? Das Programm könnte auch davon profitieren, indem 
> nach einem (automatischen oder halb-automatischen) Banken-Update ensprechende 
> Meldungen über nicht mehr gültige Konten ausgegeben würden. (So eine 
> Funktionalität ist im privaten Anwendungsbereich zugegebermaßen weniger 
> interessant als in der kommerziellen Anwendung.)

Den Nutzen eines solchen Features will ich gar nicht abstreiten. Aber
siehe oben - das gehört nicht wirklich in die Ebene, auf der HBCI4Java
arbeitet. HBCI4Java setzt im Wesentlichen das HBCI-Protokoll um, und
eine Funktion zum automatischen Aktualisieren von applikationsseitig
gespeicherten Kontoverbindungen gehört eindeutig nicht dazu.


Außerdem: die Bankenliste, die in HBCI4Java enthalten ist, ist im
wesentlichen eine "Komfort-Funktion" und kein integraler Bestandteil von
HBCI4Java. HBCI4Java funktioniert auch dann, wenn die Datei
blz.properties völlig leer ist!

In dem Fall würde HBCI4Java beim Einrichten eines HBCI-Zugangs einfach
keine Vorschläge mehr machen können, welche PIN/TAN-URL zu verwenden
ist, welche HBCI-Versionen die Bank unterstützt, usw. Auch die
automatische Kontonummer-Überprüfung beim Erzeugen eines Jobs würde
einfach immer "ins Leere" laufen und den Job ungeprüft erzeugen und zur
Bank schicken... Für andere Zwecke ist die blz.properties eigentlich gar
nicht gedacht (ich weiß, dass einige Applikationen HBCI4Java
ausschließlich für z.B. die explizite Kontonummer-Überprüfung verwenden
- aber das ist so, als würde ich Eclipse verwenden, um meine /etc/fstab
bearbeiten zu können).

Wie auch immer: die Möglichkeit, die blz.properties prinzipiell
dynamisch während der Laufzeit zu aktualisieren, macht Sinn (z.B. für
"ewig laufende" Server-Applikationen). Mit Hilfe des heute erzeugten
Patches ist das ja auch möglich. 

Das von Dir vorgeschlagene "Callback-Feature" halte ich prinzipiell
ebenfalls für sinnvoll - allerdings nicht in HBCI4Java. Vielleicht hat
ja mal jemand Lust auf ein OnlineBanking4Java - HBCI4Java könnte dabei
ein Bestandteil für die "Kommunikation mit der Bank via HBCI" sein...

Gruß
-stefan-


-- 
Stefan Palme
hbc...@ka...

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[Martin H. <ma...@st...>]

Hallo Stefan,

erstmal danke für die ausführlichen Infos.

Am Dienstag, 31. August 2010, um 13:40:54 schrieb HBCI4Java (Stefan Palme):
> Hallo,
> 
> in HBCI4Java gibt es eigentlich "schon immer" einen Kernel-Parameter,
> mit dem man steuern kann, von wo die eingebaute Bankenliste geladen
> wird. Dieser Parameter wurde bisher immer auf einen default-Wert gesetzt
> und auch (absichtlich) schlecht dokumentiert...
> 
> Habe nun die entsprechende Stelle etwas aufgebohrt, so dass eine
> Applikation jetzt z.B. auch eine URL zu dieser Datei konfigurieren kann.
> Damit ist es möglich, die Bankenliste einer Applikation aktuell zu
> halten, ohne dass die jeweils aktuellste Version von HBCI4Java
> darunterliegen muss.
> 
> Die default-Einstellung steht allerdings weiterhin für die Verwendung
> der in den HBCI4Java-Paketen mitgelieferten Datei - eine Applikation
> muss also *explizit* auf die Verwendung der online-Version dieser Datei
> umsteigen, indem der entsprechende Kernel-Parameter neu gesetzt wird.
> 
> (Die Verwendung der Online-Version der Bankenliste erzeugt übrigens ein
> neues, nicht zu unterschätzendes Sicherheitsrisiko. Falls die
> Applikation nämlich eine gefälschte Version dieser Datei bezieht - aus
> welchen Gründen auch immer - , kann es passieren, dass sie dann
> Nutzerkennungen, PINs und TANs an einen Server sendet, der in
> Wirklichkeit gar nicht zu einer Bank gehört...)

Falls man das nutzen würde, müsste diese Datei in irgendeiner Form signiert 
sein, so dass man die Quelle verifizieren kann. 

> 
> Noch was zu diesem Punkt:
> 
> On Thu, 2010-08-26 at 12:44 +0200, Martin Honermeyer wrote:
> > Eine schöne Lösung wäre wohl eine API, die die Aktualisierung der
> > Datei vornimmt und Callbacks für die Anwendung anbietet, so dass auf
> > Änderungen und -Löschungen reagiert werden kann.
> 
> Das "API für die Aktualisierung der Datei" wäre mit oben genannter
> Änderung ja gegeben. Ich nehme an, die von Dir vorgeschlagenen Callbacks
> sollen dazu dienen, dass eine Anwendung dem Nutzer gleich anzeigen kann
> "Bei Deiner Bank haben sich bestimmte für HBCI relevante Parameter
> geändert, Du musst Deine HBCI-Einstellungen /
> Konto-Konfigurationen / ... anpassen".
> 
> Das würde allerdings bedeuten, dass dieser Mechanismus auch erkennen
> muss, welche Version der Bankenliste die Applikation derzeit kennt und
> wie im Vergleich dazu die Änderungen zur neuen Version sind... usw.
> (will jetzt gar nicht alle Probleme ausführen, die mir zu diesem Feature
> einfallen).

Offensichtlich habe ich hier einen anderen (kommerziellen) Anwendungsfall als 
die meisten Nutzer der Bibliothek. Wir speichern (in-house) die Kontodaten von 
Kunden, um regelmäßige Lastschriften durchführen zu können. Die Daten werden 
von den Kunden selbst eingegeben und ich prüfe sie bei der Eingabe mit Hilfe 
von HBCI4Java (getNameForBLZ, checkAccountCRC). Im gleichen Schritt trage ich 
die Daten der Bank (BIC, Prüfalgorithmus) mit Hilfe von HBCI4Java in die 
Datenbank meiner Anwendung ein, um schnell darauf zugreifen und alte Banken 
als nicht mehr gültig markieren zu können.

Durch ein Update meiner Bankenliste wollte ich

* nicht mehr gültige Konten finden und aktualisieren bzw. löschen und die 
Kunden entsprechend informieren
* Kunden ermöglichen, Konten mit neuen, bisher unbekannten Bankleitzahlen 
angeben zu können, ohne dass die Prüfung sie ablehnt.

Bei einem Update meiner meiner Bankenliste sollte die Anwendung also zumindest 
über geänderte und gelöschte Bankleitzahlen informiert werden. In meinem 
eigenen (JRuby-)Skript habe ich diesen Mechanismus jetzt zusammen "gehackt". 
Dabei handelt es sich nicht um einen vollständigen Abgleich - ich habe nur die 
Änderungen und Löschungen aus der mir zur Verfügung stehenden letzten 
Bankenliste (von bundesbank.de) umgesetzt. 

Eine vernünftige Automatik müsste also am besten kurz nach Erscheinen mit der 
neuen Bankenliste gefüttert werden und dann entsprechende Callbacks für "Neue 
Bank", "Bank geändert" oder "Bank gelöscht" zur Verfügung stellen.


> Das geht meiner Meinung nach weit über das hinaus, was eine
> HBCI(!)-Bibliothek leisten soll/muss. Ein solches Feature wäre in einer
> etwas abstrakteren (Online-)Banking-Bibliothek weit besser aufgehoben.
> Soweit ich das sehe, entwickelt sich AqBanking von Martin Preuss in
> diese Richtung (dort wird inzwischen z.B. auch PayPal unterstützt, was
> in HBCI4Java niemals der Fall sein wird). Vielleicht mag er ja was dazu
> sagen :-)

Ich kenne z.B. Hibiscus nicht so genau, aber kann der Nutzer dort nicht auch 
Empfängerkonten speichern? Das Programm könnte auch davon profitieren, indem 
nach einem (automatischen oder halb-automatischen) Banken-Update ensprechende 
Meldungen über nicht mehr gültige Konten ausgegeben würden. (So eine 
Funktionalität ist im privaten Anwendungsbereich zugegebermaßen weniger 
interessant als in der kommerziellen Anwendung.)



Grüße
Martin

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[HBCI4Java (S. Palme) <hbc...@ka...>]

On Tue, 2010-08-31 at 15:08 +0200, Olaf Willuhn wrote:
> Ich muss zugeben, dass ich das Feature in Hibiscus nie aktiviert
> hatte. Ich wollte dem User die Daten vor dem Versand eigentlich
> noch in einem Dialog/Wizzard anzeigen, damit er sieht, was da konkret
> uebertragen werden soll. Allerdings wusste ich nicht, wie ich die
> BPDs in einer fuer den User verstaendlichen Form praesentieren
> sollte.

Hmm... Eventuell verzichte ich auch einfach darauf, die BPD mitzusenden
- die könnte der InfoPoint-Server schließlich mit Hilfe der angeblich
funktionierenden Zugangsdaten auch selbst abholen...

Dann wäre jedenfalls die Datenmenge, die versendet werden soll und die
der Nutzer nochmal zu sehen bekommen sollte, schon sehr viel geringer
und übersichtlicher...

-stefan-


-- 
Stefan Palme
hbc...@ka...

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[Olaf W. <hbc...@wi...>]

HBCI4Java (Stefan Palme) wrote:

> Mitte 2008 hatte ich in HBCI4Java mal das Konzept des
> "InfoPoint-Servers" integriert. [...]
> Leider enthält die Datenbank bis heute (zwei Jahre nach Start dieses
> Tests) ausschließlich Datensätze meiner eigenen Bank und des HBCI4Java
> Demo Servers.

Ich muss zugeben, dass ich das Feature in Hibiscus nie aktiviert
hatte. Ich wollte dem User die Daten vor dem Versand eigentlich
noch in einem Dialog/Wizzard anzeigen, damit er sieht, was da konkret
uebertragen werden soll. Allerdings wusste ich nicht, wie ich die
BPDs in einer fuer den User verstaendlichen Form praesentieren
sollte.

Gruss
Olaf

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[Martin P. <aqu...@gm...>]

Moin,

On Dienstag 31 August 2010, HBCI4Java (Stefan Palme) wrote:
[...]
> Mitte 2008 hatte ich in HBCI4Java mal das Konzept des
> "InfoPoint-Servers" integriert. Jede erfolgreiche Dialog-Initialisierung
[...]

Ah, richtig, daran erinnere ich mich.

[...]
> Nutzer geben ungern Daten raus, von denen sie selbst nichts mehr haben
> (denn zu diesem Zeitpunkt FUNKTIONIERT der betreffende Zugang ja
> bereits)...
[...]

Ja, das befuerchte ich leider auch :-/ Die Leute wollen natuerlich gerne 
solche Dienste in Anspruch nehmen, aber die Bereitschaft, *dazu* dann auch 
etwas beizutragen, ist dann oft leider doch nicht da :-/

Andererseits gibt es dann wieder Beispiele im OFX-Bereich, wo es scheinbar 
doch User gibt, die solche Daten auch weitergeben, damit andere etwas davon 
haben (www.ofxhome.com/).

[...]
> Bedarf nur noch ABRUFEN. Aber wer soll das tun? Die Idee des
> InfoPoint-Servers bestand ja genau darin, dass durch das permanente
> Füttern mit Informationen über erfolgreiche HBCI-Verbindungen
> automatisch mit statistischen Methoden herausgefunden werden konnte,
> dass sich evtl. bestimmte Zugangsdaten geändert haben...
[...]

Das fand ich auch sehr reizvoll.


Gruss
Martin



-- 
"Things are only impossible until they're not"

Martin Preuss - http://www2.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/

Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang

[HBCI4Java (S. Palme) <hbc...@ka...>]

On Tue, 2010-08-31 at 14:17 +0200, Martin Preuss wrote:
> AqBanking ist ja schon von der Anlage her eine abstrakte Online-Banking 
> Bibliothek. Banking-Protokolle werden hier durch Plugins realisiert, und eines 
> der Plugins ist halt das HBCI-Plugin (andere sind EBICS, Paypal, OFX 
> DirectConnect).

Genau das meinte ich damit - HBCI4Java wäre konzeptionell eher ein
Plugin für AqBanking und keine generische Banking-Bibliothek an sich...


> Es gabe ja schon mal Vorschlaege dazu, wie man das ganze aufbauen koennte, 
> aber wie gesagt ist das dann leider im Sande verlaufen. 

Mitte 2008 hatte ich in HBCI4Java mal das Konzept des
"InfoPoint-Servers" integriert. Jede erfolgreiche Dialog-Initialisierung
führt dazu, dass ein bestimmter Datensatz mit den dabei verwendeten
Zugangsdaten (natürlich anonymisiert) in einer zentralen DB gespeichert
wird. Bei genügend vielen derartigen Datensätzen hätte man daraus schön
ableiten können, welche Kombinationen von Zugangsdaten bei welchen
Banken funktionieren... (gemeint sind solche Sachen wie BLZ, Host,
HBCI-Version, Filter-Einstellungen, PIN/TAN-Verfahren, usw.)

Dieses Feature musste zwar explizit aktiviert werden, um dem Vorwurf zu
entgehen, HBCI4Java telefoniere ungefragt nach Haus, ist aber
einigermaßen dokumentiert und wurde auch auf der Liste und der Homepage
angekündigt.

Leider enthält die Datenbank bis heute (zwei Jahre nach Start dieses
Tests) ausschließlich Datensätze meiner eigenen Bank und des HBCI4Java
Demo Servers.

Ich gehe mal davon aus, dass der damalige Ansatz nicht funktioniert.
Nutzer geben ungern Daten raus, von denen sie selbst nichts mehr haben
(denn zu diesem Zeitpunkt FUNKTIONIERT der betreffende Zugang ja
bereits)...

Die Alternative wäre, eine solche Datenbank manuell zu pflegen, so dass
Anwendungen keine Daten mehr dorthin SCHICKEN müssen, sondern diese bei
Bedarf nur noch ABRUFEN. Aber wer soll das tun? Die Idee des
InfoPoint-Servers bestand ja genau darin, dass durch das permanente
Füttern mit Informationen über erfolgreiche HBCI-Verbindungen
automatisch mit statistischen Methoden herausgefunden werden konnte,
dass sich evtl. bestimmte Zugangsdaten geändert haben...

-stefan-


-- 
Stefan Palme
hbc...@ka...