Thread: Re: [Hbci4java-help] Aktuelle Bankenliste / SVN-Zugang
Brought to you by:
kleiner77
Menu
▾
▴
hbci4java-help
|
From: Martin P. <aqu...@gm...> - 2010-08-26 11:10:01
|
Moin, On Donnerstag 26 August 2010, 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. [...] Dazu gab es ja auch schon mal Diskussionen: So ein Dienst waere ja auch fuer die AqBanking-basierten Zugriffe interessant, d.h. man koennte sich hier sicher auch mal zusammensetzen und eine API definieren. Aber bisher ist das leider wieder im Sande verlaufen... 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/ |
|
From: Martin H. <ma...@st...> - 2010-08-31 13:59:04
|
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 |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-08-31 14:26:08
|
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... |
|
From: Olaf W. <hbc...@wi...> - 2010-08-31 15:23:04
|
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 |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-08-31 15:44:01
|
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... |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-08-31 11:41:04
|
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...) @OlafW: Wenn das für Dich bereits jetzt interessant ist sende ich Dir auch dafür das SVN-ChangeSet - Doku ist als JavaDoc enthalten. @Alle: Inzwischen haben sich relativ viele derartige kleinere Änderungen an HBCI4Java angehäuft. Allerdings haben sich im Zuge der Einführung von HBCI4Java-3 auch diverse API-Änderungen eingeschlichen. Die aktuelle Developer-Version kann man also nur noch bedingt als "HBCI4Java-2-kompatibel" bezeichnen. Allerdings ist sie auch noch weit von dem geplanten "HBCI4Java-3" entfernt. Bei Bedarf kann ich ja trotzdem mal einen aktuellen Snapshot veröffentlichen. Allerdings funktioniert dort derzeit so einiges nicht, und Support wird es dafür auch nicht geben (mir fehlt einfach die Zeit, unfertigen Code zu rechtfertigen ;-) ) 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). 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 :-) Falls - wie schon oft geschehen - mit HBCI4Java-basierter Software z.B. Verbindungsprobleme wegen geänderter URLs auftreten, könnte der geneigte Nutzer ja einfach nochmal die HBCI-Einstellungen seines Zugangs überprüfen. Sofern die Applikation das anbietet, kann diese dann anzeigen, dass die derzeit konfigurierte URL nicht mehr mit der URL aus der aktuellen Bankenliste übereinstimmt - dazu braucht es keine Callbacks oder semi-/voll-automatischen Aktualisierungs-Routinen (ich als Anwender würde diese aus Sicherheitsgründen eh deaktivieren ;-) ) Grüße! -stefan- On Thu, 2010-08-26 at 13:09 +0200, Martin Preuss wrote: > Moin, > > On Donnerstag 26 August 2010, 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. > [...] > > Dazu gab es ja auch schon mal Diskussionen: So ein Dienst waere ja auch fuer > die AqBanking-basierten Zugriffe interessant, d.h. man koennte sich hier sicher > auch mal zusammensetzen und eine API definieren. Aber bisher ist das leider > wieder im Sande verlaufen... > > > Gruss > Martin > > > -- Stefan Palme hbc...@ka... |
|
From: Olaf W. <hbc...@wi...> - 2010-08-31 12:15:50
|
Hi, > Habe nun die entsprechende Stelle etwas aufgebohrt, so dass eine > Applikation jetzt z.B. auch eine URL zu dieser Datei konfigurieren kann. [...] > @OlafW: Wenn das für Dich bereits jetzt interessant ist sende ich Dir > auch dafür das SVN-ChangeSet - Doku ist als JavaDoc enthalten. Danke fuer das Angebot. Aber ich lass das lieber so wie es ist. Die Bank-Liste ist im hbci4java.jar drin. Und das wiederrum in Hibiscus. Das wird alles zusammen signiert. Ein Online-Mechanismus ist mir an der Stelle zu heiss. Wenn die URL nicht mehr stimmt, kann der User sie ja auch manuell in der GUI aendern. > 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 :-) Oh, das taet mich auch mal interessieren. In Hibiscus haben wir mittels Scripting-Support inzwischen auch eine rudimentaere Paypal-Anbindung. Aber das ist noch nicht das, was ich mir unter "Schnittstelle" vorstelle ;) Gruss Olaf |
|
From: Martin P. <aqu...@gm...> - 2010-08-31 12:18:03
|
Moin, On Dienstag 31 August 2010, HBCI4Java (Stefan Palme) wrote: [...] > 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 :-) [...] 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). Allerdings: Die Verwaltung von Zugangsdaten waere dennoch interessant fuer alle Projekte, die mit HBCI zu tun haben, und sogar ziemlich HBCI-spezifisch (zumindest die Informationen, wie welche RDH- und PIN/TAN-Verfahren werden unterstuetzt etc). Andererseits haetten wir dann wohl auch das Problem, dass sich auch kommerzielle Anwendungen daranhaengen wuerden, und nach meiner Erfahrung natuerlich ohne selbst etwas beizutragen... Das hiesse, der Verwaltungsaufwand wuerde an uns haengenbleiben :-/ Es gabe ja schon mal Vorschlaege dazu, wie man das ganze aufbauen koennte, aber wie gesagt ist das dann leider im Sande verlaufen. Ich kann mich zum Beispiel daran erinnern, dass man sich geeinigt hatte, dass beispielsweise die URL in der Datenbank aus Sicherheitsgruenden nicht durch einfache Benutzerangabe aenderbar sein sollte, sondern dass die erst nach Pruefung durch einen der Verwalter eingetragen werden sollte. 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/ |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-08-31 12:43:04
|
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... |
|
From: Martin P. <aqu...@gm...> - 2010-08-31 13:00:24
|
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/ |
|
From: Olaf W. <hbc...@wi...> - 2010-08-31 13:08:18
|
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 |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-08-31 13:38:11
|
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... |
|
From: Olaf W. <hbc...@wi...> - 2010-08-31 14:31:20
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X