AqBanking: Unterschied zwischen den Versionen
| Zeile 105: | Zeile 105: | ||
Die erfolgreich abgerufenen Umsätze werden in einer csv-Datei unter srv/aqb/results/JobName.Umsatz.csv abgelegt, und kann leicht weiterverarbeitet werden (z.B. mit OpenOffice). | Die erfolgreich abgerufenen Umsätze werden in einer csv-Datei unter srv/aqb/results/JobName.Umsatz.csv abgelegt, und kann leicht weiterverarbeitet werden (z.B. mit OpenOffice). | ||
JobName ist bei Konsolenbedienung die niedrigste unbenutzte Zahl. Liegen die Dateien 1, 2, und 3 schon im Ordner, heißt die Datei 4.Umsatz.csv. Beispiel: | JobName ist bei Konsolenbedienung die niedrigste unbenutzte Zahl. Liegen die Dateien 1, 2, und 3 schon im Ordner, heißt die Datei 4.Umsatz.csv. Alle Dateien eines Jobs haben den gleichen JobNamen. | ||
Beispiel: | |||
http://www.orgamon.de/aqbanking/4.Umsatz.csv | http://www.orgamon.de/aqbanking/4.Umsatz.csv | ||
| Zeile 185: | Zeile 188: | ||
|- | |- | ||
|} | |} | ||
====Lastschrift==== | ====Lastschrift==== | ||
Version vom 28. März 2008, 12:42 Uhr
aqbd ist ein für Linux verfügbares Commando-Zeilen-Tool (und Dämon), das es ermöglicht ...
weitere Infos über aqbd ...
|
Überblick
Design
|
Um AqBanking für den OrgaMon nutzbar zu machen wird ein Linux-basierter REST-Webservice implementiert. Dabei dient das Gesamtsystem (Apache2+PHP+index.php+aqbd-Dämon) nur als Wrapper für grundlegende "AqBanking Rev. 3.x" Funktionen. REST hilft uns, auf Kontoumsätze und andere Informationen ganz primitiv über das Web zuzugreifen. Zum Informations-Abruf benötigt man auf der Client-Seite nur einen einfachen Webbrowser (Punkt!). Dadurch ist auch die Integration in andere Prozesse ein Kinderspiel. Ruby on Rails z.B. kann REST-Webservices direkt ansprechen. "AqBanking-REST" bietet dabei folgende Dienste an ...
|
Sicherheitsüberlegungen
- Während der Installtionsphase sollte der Webserver nur für den Admin sichbar sein, bis alles funktioniert
- Dann sollten "pin."-Dateien nur "root" sichtbar gemacht werden
- Überlegungen sollten den Rechten der Verzeichnisse ab /srv/aqb gewidmet werden
- Das Wurzelverzeichnis des REST Servers (index.php) sollte passwortgeschützt werden
- Wird der REST Server im Internet sichtbar sollte https:// (SSL-Verschlüsselung) auf das Verzeichnis gelegt werden
- Die PIN eines Kontos wird design-bedingt niemals über das Netz übertragen
- Der (HBCI-Server-)Login-Name wird design-bedingt niemals über das Netz übertragen
- Von aussen - ohne manuellen Eingriff des admin - können keine veränderte Zertifikate akzeptiert werden. Somit ist ausgeschlossen dass die Übernahme des Netzes rund um den aqbd-Host zum Stehlen von PIN / TAN führen kann
Download
Projektstatus
Erreichte Meilensteine
- Linux-Anwendungsebene: QBankingManager installieren (Erfolg: 21.02.2008)
- ein Giro-Konto abfragen um zu sehen, ob das Teil funktioniert (Erfolg: 21.02.2008)
- Transaktion "Konto-Umsatz-Abfrage" ausprobieren! (Erfolg: 21.02.2008)
- Transaktion "Sammel-Lastschrift" (DTA) ausprobieren! (Geht nicht! Nur Einzeln)
- Linux-Programmierebene: "aqbanking 3" versuchen zu compilieren (Erfolg: 19.02.2008)
- Mini-Programm Konsolen-Programm erstellen das z.B. die Kontenliste auf den Schirm bringt (Erfolg: 22.02.2008)
- AH_Job_GetBalance ("~kto~.~blz~") : double (Erfolg: 26.03.08)
- AH_Job_GetTransactions ("~kto~.~blz~","20.02.2008") : (Erfolg: 28.02.2008)
- AH_Job_MultiDebitNode_new (Achtung schwierig: "Multi-Job" + "TAN" notwendig + DTAUS Importer verwenden!) (07.03.2008)
- Erfolgreiche erzeugung eines DebitNote-Auftrags aus Kommandozeilenparametern und csv-Datei (07.03.2008)
- Erfolgreiche auftragsübertragung bis zur TAN-Abfrage über den Passwort-Callback!! (05.03.2008)
- Erfolgreiche Lastschriften mit einer einzelnen, sowie mit 2 Lastschriften in einer Sammellastchrift. (07.03.2008)
- REST - Server in PHP verwirklicht, Technologie: mod_rewrite und "$fn();" (13.03.2008)
- REST - Mappings definieren auf ein nun fertiges "aqbc"-Programm das in C programmiert ist. (13.03.2008)
- REST: Lastschriften (15.03.2008)
- Umlaute (scheinbar durchgängig UTF-8, wär ja OK!) (19.03.2008)
- Integration in den OrgaMon 1/2 "Umsatz" (20.03.2008)
- Integration in den OrgaMon 2/2 "Sammellastschrift" (26.03.2008)
Offen
- aqbd nun als richtiges / eigentständiges Linux Projekt beginnen und Know-How aus abtest übernehmen (Info: http://www.openismus.com/documents/linux/automake/automake.shtml)
- Sammellastschrift mit iTAN
- Sammellastschrift mit 2000 Posten durchführen (Massentest!)
- Grosse Kick-Off-Party für DDBAC
Anwendung als Kommandozeilen-Programm
Ausgabe bei ./abqd --help
nabqd -[U|L|B|S|D] BLZ KontoNummer PIN [Datum|"Pfad"] -U Ausgabe der Umsaetze in eine Datei -L Durchfuehren von Lastschriften -B Durchfuehren von Terminueberweisungen(Bisher nicht implementiert!) -S Ausgabe von Salden -D werde ein Daemon
Umsätze
Bedienung: -U oder -u für umsatzabfrage Danach kommen die Parameter BLZ KTO PIN [Datum] ohne - oder / oder ähnliches, nur durch whitespace getrennt
Die erfolgreich abgerufenen Umsätze werden in einer csv-Datei unter srv/aqb/results/JobName.Umsatz.csv abgelegt, und kann leicht weiterverarbeitet werden (z.B. mit OpenOffice). JobName ist bei Konsolenbedienung die niedrigste unbenutzte Zahl. Liegen die Dateien 1, 2, und 3 schon im Ordner, heißt die Datei 4.Umsatz.csv. Alle Dateien eines Jobs haben den gleichen JobNamen.
Beispiel:
http://www.orgamon.de/aqbanking/4.Umsatz.csv
| Name | Bedeutung | Beispiel |
| PosNum | vortlaufende Umsatznummer der aktuellen DATEI | 1 |
| Datum | Aktuelles Datum DD.MM.YYYY | 30.06.2008 |
| Valuta | Datum der Wertstellung | 03.07.2008 |
| Betrag | Betrag mit Dezimalkomma | 33,50 |
| Waehrung | Standard-Währungskürzel | EUR |
| Typ | Transaktionstyp (z.B.Scheck/Miscellaneous/Lastschrift) | NCHK/NMSC/NSTO |
| VorgangID | von der Bank gelieferte Numerische Entsprechung des VorgangsText, der intern übersetzt wird.
(TextKey) |
5 |
| VorgangText | Vorgangsbeschreibung die sich aus der VirgangsID ergiebt. | Lastschrift |
| PrimaNota | Von der Bank übergebene PrimaNota-Nummer | 850 |
| VonBLZ | Bankleitzahl des Bankinstitutes der Gegenseite | 66391600 |
| VonKonto | Kontonummer der Gegenseite | 10504104 |
| VonREF | Dieses Feld hat in der Bankenwelt mehrere Bedeutungen:
a) Bei Scheckeinreichungen die Dein Konto belasten wird hier die Scheck-Nummer eingetragen, bei sehr vielen Schecks, die man mit identischem Betrag draussen hat, ist diese Nummer sehr interessant, zumal "erfundene" Schecknummern (die nicht in deinem Scheck-Büchle (hoffentlich) aufnotiert sind ) hier sofort auffallen. (Oder Doppeleinreichungen) b) Bei Sammellastschriften steht hier die Anzahl der Buchungen, also "1", "2", usw. c) Bei Überweisungen die über eine Homebanking-Plattform steht hier immer eine "1", naja wird scheinbar intern als eine Art Sammelüberweisung mit nur einer Überweisung verbucht oder so ... |
|
| VonName1; | Kontoinhaber der Gegenseite | Andreas Filsinger |
| VonName2 | Selten genutzte zweite Namensspalte ebenfalls Kontoinhaber | Filsinger GmbH |
| Buchungstext1-7 | Verwendungszweck. Maximal 27 Zeichen pro Zeile, Maximal 7 Zeilen | Ihr Einkauf bei Tante Emma |
Lastschrift
Bedienung -L oder -l für Lastschrift Danach kommen die Paramter BLZ KTO PIN "Pfad der CSV-Datei" ebenfalls ohne sonderzeichen, nur durch whitespace getrennt
Die CSV-Datei ist Semikolon getrennt, und die Zeilenumbrüche sind mit \r\n ausgeführt. RID ist eine durchlaufende beliebige Nummer(Primary Key) und wird vom Parser ignoriert, ebenso wie Ort. Diese beiden Felder dürfen jedoch nicht weggelassen werden!!! Jede Zeile ist ein neuer Datensatz, und wird vom Programm als jeweils einzelne Lastschrift in eine Sammellastschrift verpackt und ausgeführt.
RID;Name;Ort;BLZ;Konto;Betrag;VZ1;VZ2;VZ3;VZ4 1;"MARTIN SCHMIDT";"";66391600;0002076616;0,25;"TESTABBUCHUNG8";"REV. 1.005";"";""
Nach der Jobverarbeitung wird die Lastschrift-CSV als JobName.csv In results bzw. error kopiert.
Salden
Bedienung: -S oder -s für Saldo Danach kommen die Parameter BLZ KTO PIN ohne - oder / oder ähnliches, nur durch whitespace getrennt
Das Ergebnis wird bei erfolgreicher Saldenabfrage als JobName.Saldo.csv in results gespeichert.
Betrag;Waehrung 1000000,00;EUR;
Anwendung als Dämon für den Serverbetrieb
Dämon (-D)
Es werden zwischen den verschiedenen Programmebenen Daten ausgetauscht, indem Files auf der Festplatte abgelegt werden. (Von der DBUS-Technologie sind wir abgekommen, schlicht und einfach wegen der enormen, und für unsere Zwecke zu hohen, komplexität der DBUS-Bibliothek.)
Job-Files
Wird abtest mit -d als Parameter gestartet befindet sich die Anwendung im "Deamon-Mode". Aufträge werden mit in sogenannten JobFiles in das jobs-verzeichnis geschrieben, und von abtest gelesen. Der Inhalt der Files ist identisch mit den in der Kommandozeile zu übergebenden Parameter.
-s 66091600 1234567 gespeichert als JobName.job im Unterverzeichnis jobs bzw. /srv/aqb/jobs
Sind die Jobs Abgearbeitet werden sie je nach erfolg zusammen mit den Ergebnisdaten bzw mit den Lastschrift-Daten im csv- Format in den results ordner, oder in den error-ordner verschoben. Uber jede Aktion werden log-Dateien geschrieben.
Tan-Übergabe
Die Tan wird ab Sommer 2008 im iTan-verfahren abgefragt, und ist damit nichtmehr frei wählbar. Die Aufforderung lautet dann in etwa: "Bitte die 17.TAN eingeben: ". Damit muss während eines Lastschriftverfahrens die Gegenseite gerufen werden. Dafür wird die Anforderung der Bank in einem File Gespeichert, und muss innerhalb von 20sec mit einem tanFile "beantwortet" werden.
Dazu legt aqbd nach start der Jobverarbeitung im Verzeichnis /srv/aqb/results/ eine Datei namens JobName.tan-anfrage.txt mit dem Anfragetext der Bank an, und wartet anschließend 20 Sekunden auf das Auftauchen der Datei JobName.tan unter /srv/aqb/jobs. Diese darf AUSSCHLIEßLICH die tan enthalten und wird nach Abschluss der Jobverarbeitung ebenfalls in error bzw. results kopiert.
PHP-Rest-Server
Die erste Alphaversion des Rest-Servers ist jetzt online, und arbeitet super mit abtest zusammen. abtest läuft im Daemon-Modus im Hintergrund, und wird sozusagen vom Restserver ferngesteuert. Das skript erzeugt die Job-Files und prüft auf das Vorhandensein der Ergebnissdaten, und gibt diese aus. Die ersten Dauertests für den Daemon stehen ebenfalls aus.
Anfrage auf den server http://www.orga-mon.de/rest/Funktion/BLZ/KTO/datum Funktionen: ./info/ ./umsatz/ ./saldo/ ./lastschrift/ ./itan/
Umsatz (./umsatz/)
Anfrage:
./UMSATZ/~BLZ~/~KONTO#~/2008-02-28?f=text
Antwort:
- Mapping csv<->Aqbanking
// Zuordnungen gefunden
Buchungsdatum<->date
Typ<->transactionKey (Beispiel: "NSTO","NMSC","NCHK")
vonBLZ<->remoteBankCode
vonKonto<->remoteAccountNumber
vonName1..2<->remoteName
ValutaDatum<->valutaDate
Betrag<->value.value
Waehrung<->value.currency
VorgangID<->textKey
VorgangText<->transactionText
Primanota<->primanota
Verwendungszweck1..7<->purpose
Sammellastschrift (./lastschrift)
Anfrage 1/2
POST ./lastschrift/~BLZ~/~Konto~
mit einem zeitgleichen http-Upload der DTA-Datei (Name spielt keine Rolle)!
Antwort:
- die Antwort ist, sobald die DTA-Datei fehlt ein kleines Upload-Formular, mit dem man die Anfrage (diesmal mit Datei) wiederholen kann.
- iTAN: Ist das iTAN Verfahren gewählt, so muss vom Server vor Anzeige der Antwort zunächst die Index-Nummer der iTAN abgefragt werden
- ansonsten ist die Antwort eine Text der Bank, die Informationen zur TAN-Eingabe enthält:
JobID: 293837 Nun bitte die 34. TAN eingeben
- Mit Hilfe dieser Meldungen muss man eine zweite RESTful Anfrage formulieren. Diesmal mit JobID und TAN. Dazu hat man ein Zeitfenster von 20 Sekunden.
Anfrage 2/2
GET ./itan/~JobID~/~TAN~
Nun erfolgt die TAN-Übergabe an die Bank und die tatsächliche Durchführung. War die Ausführung erfolgreich, so erscheint ein einfaches "OK".
Kontostand (./saldo)
Termin-Überweisung
-- noch kein Bedarf --
Installations-Anleitung (aqbd)
aqbd compilieren
- gwen-Lib installieren
tar xzfz gwenhywfar-3.2.0.tar.gz cd gwenhywfar-3.2.0 ./configure make make install
- aqbanking-Lib installieren
tar xzfz aqbanking-3.3.0.tar.gz cd aqbanking-3.3.0
Wir haben beide Packages in das Verzeichnis /usr/src entpackt.
Im Moment müssen noch 2 Patches eingespielt werden:
Pachtes
Vertuschung von BLANK-BLANK
- swift.c,
int AHB_SWIFT_Condense(char *buffer) {
char *src=buffer;
char *dst=buffer;
while(*src) {
if (*src!=10) {
*dst=*src;
dst++;
}
src++;
} /* while */
*dst=0;
return 0;
}
einstellige REF
- aqbanking/src/plugins/parsers/swift/swift940.c
Alt:
00426: /* customer reference (M) */
00427: if (bleft>1) {
Neu:
00426: /* customer reference (M) */
00427: if (bleft>0) {
Umlaute im DTA
- imexporter.c
imexporter.c:1562 (ALT)
c=toupper(c);
if (!(isdigit(c) ||
(c>='A' && c<='Z') ||
(c>='a' && c<='z') ||
(strchr(" .,&-+*%/$", c))))
imexporter.c:1562 (NEU)
c=toupper(c);
if (!(isdigit(c) ||
(c>='A' && c<='Z') ||
(strchr(" .,&-+*%/$[\\]~", c))))
./configure --disable-tutorials --disable-chipcard-client --with-frontends="" --with-backends="aqhbci" make make install
Danach kopieren der abtest.c-source (einfach die alte überschreiben) in das Verzeichnis /usr/src/aqbanking-3.2.1/src/test.
Kompilieren der Source
touch abtest.c make abtest
Da unser Server ein 64bit-System ist, mussten wir vor dem Anlegen der Konten noch alle libaq*.so von var/lib nach Var/lib64 kopieren.
Konto - Deklaration
- Vorbereitung, wir brauchen ...
- BLZ
- HBCI-URL (http://www.hbci-zka.de/institute/institut_auswahl.htm)
- Kontonummer
- Benutzerkennung
- PIN
Benutzer anlegen
aqhbci-tool3 adduser -b BLZ -u Benutzerkennung -s HBCI-URL -t pintan
Konto anlegen
aqhbci-tool3 addaccount -b BLZ -c Benutzerkennung -a Kontonummer
Systeme miteinander bekanntmachen
- Ein notwendiger Schritt damit AqBanking genau speichern kann, was die Gegenstellen für Fähigkeiten und Vorlieben hat.
aqhbci-tool3 getsysid -b BLZ -c Benutzerkennung
- kommt der Fehler "A TLS packet with unexpected length was received" muss man SSL3 (anstelle von SSL2) aktivieren.
SSL3 aktivieren
- falls erforderlich (siehe oben) diese eine (grüne) Zeile in der Datei
~/.aqbanking/settings.confeinfügen ...
users {
user {
char userId="~Dein-HBCI-User-Login-Name~"
data {
backend {
...
char userFlags="forceSsl3"
char tokenType="pintan"
...
Sammellastschrift nutzbarmachen
- rote Zeile rauslöschen ...
char multiJobAllowed="N"
... auch wenn mal nur eine Lastschrift verbucht werden soll.
das Flag "PreferSingleDebiNotes" rausmachen
prefersingletransfer 0x00000001 : Einzelüberwisung bevorzugt, für uns unwichtig
prefersingledebitnote 0x00000002 : Ist default, wird einfach aus der settings.conf entfernt, SingleDebinote gibt es nicht bei VoBa!
Zertifikat speichern
- Wechsle ins Verzeichnis /srv/aqb
- Führe eine erste Saldoabfrage durch
aqbd -S ~BLZ~ ~Konto#~ ~PIN~
- Das Programm bricht mit einem Zertifikatsfehler ab
- Umbenennen der frisch erstellten "cert.~BLZ~.~KTO~.tmp"-Datei nach "cert.~BLZ~.~KTO~.txt"
PIN dauerhaft speichern
Erstelle eine Datei "pin.~BLZ~.~KTO~.txt" in /srv/aqb. In ihr darf nur die PIN in einer Zeile enthalten sein, keine Kommentare oder Leerzeilen.
erster Test
aqbd -U ~BLZ~ ~KontoNummer~ ~StartDatum~
Die Umsätze ab ~StartDatum~ werden angezeigt.
Installations-Anleitung (REST)
Apache2 anpassen
REST Server PHP-Script
erster Test
http://~MeinServer~/saldo/~MeineBLZ~/~MeineKontoNr~/
Ergebnis
Betrag;Waehrung
2938,23;EUR
Links
Aqbanking 3
- Homepage: http://www.aquamaniac.de/sites/aqbanking/index.php
- Developement-Snapshot-aqbanking: http://devel.aqbanking.de/viewsvn/aqbanking
- Mailing-List: http://sourceforge.net/mailarchive/forum.php?forum_name=aqbanking-devel
Alternative Projekte
- http://openlab.radion.org/lab/Konsolenbasiertes_Online_Banking_mit_Linux (diese Implementierung basiert auf dem veralteten "aqbanking 2")