JAVA 6/7 und Hibiscus unter Win7

machst du dass ganze jetzt eigentlich nur wegen dem DKBVisa Script? ich weiß jetzt nicht grad welchen Wiki-Eintrag du da meinst und wie alt der ist.

Aber bei mir laufen alle Scripts unter 1.7.0_05 (in 64bit!) oder unter 1.7.0_17 (in 32bit!) problemlos! welche Bit hast du denn installiert? (meine Jameica-Installation unter Win7-64bit verwendet auch meine 64bit-Javaversion)

Hat ja auch weniger mit dem Script (JavaScript nicht Java) selbst zu tun als wenn dann mit HTMLUnit (Java-Bibliotheken) und wie gesagt da achte ich im Moment wenig auf die Java-Version?!

Zudem gibts da doch einen Workaround um bei Java 1.7 die alte SSL wieder einzuschalten?! steht auch hier im Forum ... (aber wie gesagt hab ich bestimmt nicht für ein Script so gemacht)

Gruss TheDudge

Also....

ich habe jetzt mal von "manuell" installierter HTMUnit und DKBVISA.js auf die Repository-Variante umgestellt:

HTMLUnit 2.10
DKBVISA 1.26
(JAVA 1.7.0_21-b11)

Ergebnis: Ohne den JAVA7 "Workaround", also Erlauben von MD2, läuft da bei DKBVISA gar nichts.

Wie früher gesagt: DKB HBCI Zugriff mit JAVA 7 problemlos.

DKBVISA macht jetzt aber letztendlich doch nicht anderes, als sich beim Browser-Banking anzumelden, einen CSV-Export der Umsätze anzustarten und diesen dann in Hibiscus-Umsätze zu verarbeiten.

Wenn ich mit Firefox am Browser-Banking der DKB anmelde, dann zeigt mir FF an, dass ich per RC4 verbunden bin. Entsprechend der jüngsten ct' Artikel, dass RC4 mittlerweile zumindest theoretisch auch schon
kompromittiert ist, habe ich da vor einiger Zeit schon geprüft, das auch Verbindungen über AES möglich sind.

Also an der DKB liegt das Problem (diesmal) wohl kaum.

So wie ich das verstehe, ist die HMTLUnit doch so was wie ein "Browser für Skripts", gibts da nicht irgendwo Optionen, welche Verschlüsselung bevorzugt genutzt werden soll?
Ich habe mich mal oberflächlich in die Dokus zu HMTLUnit eingelesen, da kann man den gewünschten Browser als Parameter übergeben: Wäre z.B. für IE8 im DKBVISA.js im Aufruf des Clients, Zeile 435:

webClient = new WebClient(BrowserVersion.INTERNET_EXPLORER_8);

IE9 und der in der Doku angegebene FF 17 werden von HMTLUnit 2.10 anscheinend noch nicht unterstützt.

Sei es aber drum, ändert noch nichts am Problem

Hat TheDudge da evtl. noch eine Idee?


Daneben würde mich nach wie vor interssieren, wie Jameica "seine" JRE auswählt. Da JAVA_HOME ein Flop war, hab ich weiter gesucht und glaube verstanden zu haben, dass diese Variable nur für JDKs, nicht für JREs ausgewertet wird. Anscheinend wird unter Win7 64 über den Wrapper "jameica-win64.exe" auf die Windows-Registry zugegriffen und die dort als Default eingetragene JVM gestartet.

Kann man das beeinflussen?

thedudge: Wie kann ich Dich überzeugen, dass das Skript NICHT mit JAVA 7 OHNE den Workaround mit erlaubter MD2 Verschlüsselung läuft?

Vielleicht durch den Log-Auszug?

[Tue Apr 30 17:55:42 CEST 2013][ERROR][de.willuhn.jameica.scripting.messaging.InvokeMessageConsumer.handleMessage] error while executing script method wiedenhoeftNet_dkbVisa_Js_kontoSync, adding exception to return list
javax.script.ScriptException: sun.org.mozilla.javascript.internal.WrappedException: Wrapped javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints (<Unknown source>#575) in <Unknown source> at line number 575


Wie gesagt, es sieht so aus, als würde die HTMLUnit per Default MD2 haben "wollen", was die DKB (noch) unterstützt.

Noch - daher finde ich dieses Problemchen trotz Workaround dennoch spannend und nachverfolgenswert. Und helfe dabei, wenn möglich, gerne mit.

Bei Linux geschieht das ueber die Variable $PATH. Bei Windows sucht der Launcher die passende Java-Version. Wie genau das implementiert ist und welche Registry-Zweige da gelesen werden, kann ich dir auch nicht sagen. Die EXE-Datei erzeuge ich mit "Launch4J". Die zugehoerige Config-Datei findest du hier: https://github.com/willuhn/jam…-win32.xml