[gnucash-de] Neue Release-Welle

[Martin Preuss]

Moin,

diese Wochenende habe ich mal wieder so richtig in C-Code gebadet ;-)

Das Ergebnis sind die aktuellen Sonntag-Abend-Releases von:
- Gwenhywfar
- AqBanking
- AqHBCI
- AqHBCI-QT-Tools
- AqHBCI-DDVCard
- AqHBCI-RSACard
- LibChipcard2

Die groessten Aenderungen gab es dabei in AqHBCI und Konsorten. Hier wurde 
historisch gewachsener Code (AqHBCI war zu Beginn stand-alone und 
ausgerichtet gleichzeitig Client und Server sein zu koennen) geglaettet.
Auf diesem Gebiet gibt es noch manches zu tun, aber da AqHBCI laeuft ist das 
nicht dringend. Und da keine auesseren Programme/Bibliotheken von AqHBCI 
abhaengen, kann ich da auch spaeter noch dran basteln.

Veraendert habe ich nun das Medium-Interface: Grundsaetzlich muss jetzt eine 
DDV- oder RSA-Karte im normalen Betrieb nix mehr ueber Benutzer und Banken 
wissen. Im Normal-Betrieb geht es ja nur darum, die Schluessel der Karte zu 
verwenden. Bei manchen vorpersonalisierten RSA-Karten geht sogar auch gar 
nichts anderes, die wissen naemlich tatsaechlich nichts ueber Benutzer ;-)

Darauf ist das aktuelle Interface nun vorbereitet. Damit kann man diese Karten 
zwar immer noch nicht nutzen, aber jetzt wird es zumindest theoretisch 
moeglich. Der Rest muss nun noch implementiert werden.

Verbessert wurde dabei allgemein das DDV-Card-Plugin: Es ist jetzt ca 16 % 
schneller ;-) Weil die Karte nix mehr ueber Benutzer wissen muss, liest sie 
auch nicht mehr jedesmal die User-Daten aus. Dies geschieht jetzt nur noch 
einmal, dabei werden auch die Schluessel-Informationen (Nummer, Version) 
gelesen. Beides wird dann von AqBanking/AqHBCI gecached.

Ausserdem habe ich wieder am SSL-Code gebastelt, speziell: An der Nachfrage 
bei Zertifikaten. Zum einen werden nur noch neue Zertifikate wirklich 
gespeichert, zum anderen reagiert AqHBCI nun besser auf temporaer-akzeptierte 
Zertifikate. Vorher wurde da *jedes* Mal nachgefragt, und das waren pro 
Verbindung dann mindestens 3 Fragen ;-)

Wenn man jetzt anklickt "nur diese Sitzung" wird die Antwort auch solange 
gespeichert, bis die Auftraege gesendet sind, also im Prinzip solange der 
HBCI-Dialog besteht. Danach werden die Antworten geloescht, so dass beim 
naechsten Dialog wieder nachgefragt wird (eben so wie es geplant war).

Wenn man ein Zertifikat permanent akzeptiert wird es wieder wie ueblich 
gespeichert und jetzt tatsaechlich erst wieder nachgefragt, wenn sich das 
Zertifikat geaendert hat bzw. OpenSSL via Gwen einen anderen Fehlercode 
sendet als vorher.

Ausserdem habe ich einen lange Zeit misterioesen Fehler behoben: Mitunter 
flackerte der Fortschrittsbalken kurz zwischen 0 und 100 Prozent...
Als ich angefangen habe ein Konsolen-Frontend zu erstellen (fuer's naechste 
AqMoney, dann AqMoney3), habe ich den Fehler gefunden: Ein WaitCallback wurde 
ein wenig illegal verwendet ;-)

Eine weitere Vorbereitung in Richtung AqMoney3 ist das Einrichten von 
geteilten Daten in AqBanking. So werden beispielsweise QBankManager und 
AqMoney3 die Transaktionsdaten gemeinsam verwenden (wie frueher KOpenHBCI und 
AqMoney1).

AqBanking hat zusaetzlich noch Verbesserungen in den Makefiles: Nun wird 
alles, was man mit "make" erstellt, tatsaechlich gegen die aktuell 
entstehende Bibliothek gelinkt.

Ein anderes Problem konnte auch behoben werden: Ebenfalls durch die Arbeit am 
Konsolen-Backend ist mir aufgefallen, woher die von einigen Benutzern 
gemeldeten Doppel-Eintraege stammen. Das passierte immer dann, wenn man mit 
GnuCash Umsaetze abgerufen hatte und anschliessend mit QBankManager nochmal.

Da GnuCash offensichtlich wegen des Fehlers in AqBanking seine Auftraege nicht 
aus "finished" geloescht hat (was uebrigend auch voellig in Ordnung so ist), 
lagen die fuer das naechste GatherResponses() von QBankManager noch da. Damit 
konnte QBankManager nicht mehr unterscheiden, ob die Transaktionen nun schon 
doppelt von der Bank gekommen sind (was durchaus normal sein kann, einer der 
Schwachpunkte von HBCI), oder wo sie sonst herkommen.

Das Problem ist nun doppelt behoben ;-)

Und schlussendlich: Der bei Christian sehr sporadisch und nicht 
reproduzierbare Fehler, dass eine Nachricht nicht entschluesselt werden 
konnte, konnte dank Christians' Logs extrem wahrscheinlich gefixed werden.


Fazit: Ich empfehle dringen ein Update ;-)


Gruss
Martin


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

LibChipcard - http://www.libchipcard.de/
AqBanking - http://www.aquamaniac.de/aqbanking/
OpenHBCI - http://www.openhbci.de/