everflux

Schon in frühen Beta Versionen von Ubuntu 11.04 / Oneiric hat Netbeans mich ständig nach einem „Master Password“ gefragt, mit dem gespeicherte Passwörter von Netbeans gegen unbefugten Zugriff verschlüsselt werden.

Das ist nervig, denn bisher ging es auch ohne – dabei nutzt Netbeans die von modernen Betriebssystemen bereitgestellte native Infrastruktur um Passwörter zu speichern. (z.B. Keychain auf dem Mac, Gnome-Keyring o.ä.) Normalerweise funktioniert das auch – aber seit Gnome 3 hat sich da offenbar etwas geändert.

Debuggen kann man die Netbeans Keyring Integration indem man folgende Option in der etc/netbeans.conf zu den netbeans_default_options ergaenzt:

-J-Dorg.netbeans.modules.keyring.level=0

Anschließend sieht man in ~/.netbeans/7.0/var/log/messages

FINE [org.netbeans.modules.keyring.kde.KWalletProvider]: application exit with code 2 for commandString: [qdbus, org.kde.kwalletd, /modules/kwalletd, org.kde.KWallet.isEnabled]; errVal: Service 'org.kde.kwalletd' does not exist.
FINE [org.netbeans.modules.keyring.gnome.GnomeProvider]
java.lang.UnsatisfiedLinkError: Unable to load library 'gnome-keyring': libgnome-keyring.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:379)
at org.netbeans.modules.keyring.gnome.GnomeKeyringLibrary.<clinit>(GnomeKeyringLibrary.java:62)
[catch] at org.netbeans.modules.keyring.gnome.GnomeProvider.enabled(GnomeProvider.java:88)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:72)
at org.netbeans.api.keyring.Keyring.save(Keyring.java:109)
at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry$5.run(ServerRegistry.java:731)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)

Nachdem ich sichergestellt habe, dass die Library installiert ist:

sudo apt-get install libgnome-keyring0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgnome-keyring0 is already the newest version.

bleibt die Frage: Wieso findet Netbeans die gesuchte Library nicht? Die Lösung: Die Gnome Keyring Library ist nur noch mit einem anderen Dateinamen verfügbar, mit angehängter „0“. Das gab es zwar früher schon immer, dass die Libraries ohne Versionsnummer (oder was das ist) lediglich ein Symlink auf die „echte“ Library waren, aber immerhin gab es die. (Da gibt es bestimmt einen guten Grund und viel Logik für, dass das abgeschafft wurde – mir erschließt sich das jedoch nicht.)
Der simple Work-Around ist daher:

sudo ln -s /usr/lib/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so

und danach funktioniert Netbeans wieder tadellos. Also gab es offenbar keine inkompatiblen API Änderungen, sondern „lediglich“ eine Änderung des Library-Namens. Ob das ein Ubuntu/Debian Paketierungsproblem ist, oder ab Gnome 3 einfach die neue Marschrichtung, kann ich nicht sagen.

Update: Ich hab dazu ein Bug im Netbeans Issuetracker aufgemacht. Wer voten möchte – gerne: http://netbeans.org/bugzilla/show_bug.cgi?id=203735

Bei Caliper handelt es sich um ein Framework um Mikrobenchmarks für Java Programme durchzuführen. Caliper ist bei Google code gehostet – http://code.google.com/p/caliper/ – und steht unter der Apache 2 Lizenz, kann somit sehr frei verwendet werden.

Caliper verfolgt einen ähnlichen Ansatz wie JUnit, Methoden müssen mit „time“ als Prefix benannt werden, und einen Parameter vom Typ int entgegennehmen um dann ausgeführt zu werden. Dieser Parameter gibt an, wie viele Iterationen der zu messenden Methode durchzuführen sind.

Leider ist Caliper bisher noch nicht in einer Version 1.0 released worden, daher bleibt nur selber bauen. Derzeit ist das jedoch auch nicht ganz einfach: Caliper haengt von Google Guava ab, nutzt in der svn-trunk Version dazu auch bereits Features von Guava r10, was auch noch nicht released ist. Also auch hier: Selber bauen, und die Abhängigkeit in Caliper korrigieren. Mein favorisiertes Build Tool ist in diesem Fall maven.

Möchte man noch während des Benchmarks die Speichernutzung analysieren, so bietet Caliper dies auch an – über einen Java Agent der von dem Google Projekt java-allocation-instrumenter (http://code.google.com/p/java-allocation-instrumenter/, Apache 2 Lizenz) bereitgestellt wird. (Leider ist hier derzeit der Maven Build nicht so konfiguriert, dass als Artefakt ein nutzbarer Java Agent erzeugt wird. Dies ist im Ant basierten Build in Ordnung, und kann mit einem kleinen Patch der Maven Konfiguration auch behoben werden.)

Der letzte Wehrmutstropfen bleibt nun, dass Caliper gerne eine Environment Variable, statt bspw. einem System Property, hätte, um den zu nutzenden Java-Agent zu spezifizieren – diese lässt sich bei Ausführung als Script zwar einfach setzten, jedoch aus einer Java Anwendung heraus eigentlich nicht. Dazu später mehr.) Weiterlesen »

Drools (und JBoss Rules) funktioniert derzeit (Drools 5.2) nicht out-of-the-box mit Java 7 (OpenJDK bzw. Oracle Java 7). Der Grund ist, dass der von Drools verwendete Compiler lediglich Support bis Java 6 hat.

Eine einfache Loesung, die auch mit Java 7 funktioniert, ist die zu verwendende Java Version manuell zu konfigurieren, wenn man die KnowledgeBuilderFactory konfiguriert:

final Properties props = new Properties();
props.setProperty("drools.dialect.java.compiler.lnglevel", "1.6");
final KnowledgeBuilderConfiguration configuration = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(props, getClass().getClassLoader());

Weitere Probleme mit Java 7 und JBoss Drools sind mir bisher nicht aufgefallen.

Lange gesucht, doch gefunden:

ERROR: Aborted Maven execution for InterruptedIOException
java.net.SocketTimeoutException: Accept timed out


Jenkins (bzw. Hudson) bricht dann mit dieser Fehlermeldung den Build Prozess ab:

java.net.SocketTimeoutException: Accept timed out
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
	at java.net.ServerSocket.implAccept(ServerSocket.java:462)
	at java.net.ServerSocket.accept(ServerSocket.java:430)
	at hudson.maven.AbstractMavenProcessFactory$SocketHandler$AcceptorImpl.accept(AbstractMavenProcessFactory.java:167)
	at hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:221)
	at hudson.maven.ProcessCache.get(ProcessCache.java:231)
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:668)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429)
	at hudson.model.Run.run(Run.java:1374)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:145)
Finished: ABORTED

Beheben über advanced und dort in die MAVEN_OPTS hinzufügen:

-Djava.net.preferIPv4Stack=true

Anschließend sollte der Build wieder korrekt funktionieren. Alternativ kann man dies auch als globale Environment Variable setzen, das Problem wird mehrere Java Anwendungen betreffen und nicht nur den CI Server.

Nachdem ich (wie im vorherigen Artikel beschrieben) nun OpenJDK / Java 7 selber kompiliert habe, habe ich mich auf die Suche nach dem SSL Problem gemacht, dass ich mit Jameica/Hibiskus habe. (No offense, ich find es leichter OpenJDK zu übersetzen oder anzupassen als Jameica und Hibiskus zu bauen… praktischerweise bringt OpenJDK auch Netbeans Projektdateien mit, so dass es ein Klacks ist, das Projekt mit Netbeans zu verwenden.)

Nachdem ich folgenden Patch geschrieben habe habe:

diff -r 9b8c96f96a0f src/share/classes/sun/security/ssl/SSLContextImpl.java
--- a/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jun 27 13:21:34 2011 -0700
+++ b/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jul 25 19:30:11 2011 +0200
@@ -871,7 +871,7 @@
                 }
             } catch (CertPathValidatorException cpve) {
                 throw new CertificateException(
-                    "Certificates does not conform to algorithm constraints");
+                    "Certificates does not conform to algorithm constraints", cpve);
             }
         }
     }

ist jetzt auch zu sehen, was die Ursache fuer den SSL Fehler ist:

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed: MD2withRSA
	at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:200)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:870)
	... 21 more org.kapott.hbci.manager.HBCIUtils.log(HBCIUtils.java:1052)

OpenJDK kommt übrigens ohne Root Zertifikate daher, so dass man sich nicht über einen solchen Dialog wundern sollte:

Nachdem man die Exception genauer ansieht, ist man auch etwas schlauer geworden: Irgendein Zertifikat ist mit einem nicht mehr als sicher geltenden Algorithmus signiert. Das der Apobank selbst ist es offensichtlich jedoch nicht, also muss die gesamte Zertifikatskette untersucht werden.
Hier habe ich etwas Shell-Magie und das OpenSSL Kommandozeilentool verwendet:

openssl s_client -showcerts -connect hbcibanking.apobank.de:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("cert-" c ".pem")}/---END CERTIFICATE-----/{inc=0}'; for i in cert-?.pem; do openssl x509 -noout -serial -subject -issuer -in "$i"; done

Danach finden sich alle Zertifikate in cert-1.pem, cert-2.pem usw., die Ausgabe der Seriennummern, Subject und Issuer sah bei mir so aus:

serial=4FCD4C50631D3BB4C747A319E816AD5D
subject= /C=DE/ST=NRW/L=Duesseldorf/O=Deutsche Apotheker- und Aerztebank/OU=Terms of use at www.verisign.com/rpa (c)05/CN=hbcibanking.apobank.de
issuer= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
serial=254B8A853842CCE358F8C5DDAE226EA4
subject= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
serial=70BAE41D10D92934B638CA7B03CCBABF
subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Nun müssen alle Zertifikate untersucht werden:

openssl x509 -text -in cert-0.pem

Und entsprechend für die anderen Zertifikate in der Kette. Ich wurde dann bei dem dritten Zertifikat fündig:

tkruse@charix:~$ openssl x509 -text -in cert-2.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority

Ein „betagtes“ altes VeriSign Zertifikat das mit MD2 und RSA signiert wurde. Auch wenn der MD2 Signaturalgorithmus noch nicht gebrochen ist, gibt es einige Angriffe, die dazu geführt haben, dass MD2 seit 2009 nicht mehr in OpenSSL verwendet wird.
Was heißt das nun für das konkrete SSL Problem? Die ApoBank wird sich eh um Januar 2012 herum spätestens ein neues SSL Zertifikat besorgen. Dann sollte der Spuk zu ende sein. Besser wäre es allerdings wenn die betroffenen Anbieter ihre SSL Zertifikate jetzt erneuern – es geht schließlich um Online Banking!
Und wieso fällt das erst seit Java 7 auf? Seit Java 7 ist offenbar die Möglichkeit neu hinzugekommen die Algorithmen zu prüfen oder wurde geändert. Eigentlich sollte seit Java 6u17 bereits MD2 nicht mehr unterstützt werden, zumindest gibt es einen entsprechenden Eintrag in den Release notes: http://www.oracle.com/technetwork/java/javase/6u17-141447.html.

Ich habe ein merkwuerdiges SSL Problem mit Java 7 (Build 147, dem Release Candidate) im Zusammenhang mit Online-Banking und Jameica/Hibiskus:

Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
 at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:873)
 at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:804)
 at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1319)
 ... 19 more

Schaut man sich dazu den Source Code an, sieht man schnell, dass leider die verursachende Exception verschluckt wird. (Das kommt davon, wenn Committer und Reviewer identisch sind…)
Meine Idee war also, OpenJDK selber zu bauen und da ggf. besseres Logging einzubauen. Die im Internet veröffentlichten Anleitungen sind alle ein paar Jahre alt und nicht mehr ganz korrekt, daher hier meine Ergebnisse zum Nachmachen.
Ich habe Ubuntu als System verwendet, dort ist eine Übersetzung von OpenJDK / Java 7 sehr einfach.
OpenJDK wird mittels Mercurial verwaltet, zur Hierarchiebildung wird die Mercurial Forest extension benötigt (und Mercurial). Ist das „mercurial“ Paket bereits installiert so kann man die Forest extension einfach herunterladen:

hg clone http://bitbucket.org/pmezard/hgforest-crew hgforest

Diese muss nun in die .hgrc eingetragen werden: (das „….“ durch den Pfad zum Download ersetzen)

[extensions]
forest=......hgforest/forest.py
fetch=

Danach installiert man die Build Abhängigkeiten:

sudo apt-get install build-essential gawk libasound2-dev libfreetype6-dev libcups2-dev libxt-dev libx11-dev libxtst-dev libxrender-dev

Und checkt per mercurial-forest die Sourcen fuer OpenJDK aus:

hg fclone http://hg.openjdk.java.net/jdk7/jdk7 jdk7

Da beim späteren Build noch Java Abhängigkeiten heruntergeladen werden müssen, hab ich noch folgendens in die Ant Konfiguration eingesetzt: ~/.antrc

ANT_OPTS=”$ANT_OPTS -Dallow.downloads=true”

Für den build benötigt man ein existierendes Java, und setzt folgenden Umgebungsvariablen:

export ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
unset JAVA_HOME
export LANG="C"
make sanity

Da sollten keine Fehler zu sehen sein und gibt dann den „make“ Befehl (dauert bei mir rund 40 Minuten):

make

Und kann es dann aus dem aktuellen Verzeichnis testen ob „java“ vorhanden ist:

build/linux-amd64/bin/java -version

Bei mir sieht das dann folgendermassen aus:

openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-tkruse-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

Fertig.
(Ja man benötigt wirklich keine „binary plugs“ o.a“. mehr!)

Update: Für Ubuntu 12.04 benötigt man folgende Pakete:

libcups2-dev, libfreetype6-dev, liboss4-salsa-dev

Und muss (Stand Mai 2012) auch wegen der neueren Kernelversion als die bei OpenJDK bekannten eine Environment Variable setzen:
export DISABLE_HOTSPOT_OS_VERSION_CHECK=ok

Hibiscus ist ein Plugin für Jameica – zusammen ergibt sich daraus ein Homebanking Programm das auf verschiedenen Betriebssystemen läuft (überall wo Java verfügbar ist), die Software kann hier heruntergeladen werden.

Die normale Abfrage von Konten erfolgt über HBCI – dies Protokoll wird jedoch leider nicht von jeder Bank bzw. jedem Finanzdienstleister für alle Produkte unterstützt. So ist Paypal z.B. nicht per HBCI abfragbar, und auch die recht populären DKB Kreditkarten Konten nicht.

In neuen Versionen unterstützt Jameica auch Scripting und sogenannte Offline-Konten. Das sind Konten, die nicht per HBCI abgefragt werden, sondern von Hand gepflegt werden. (Z.B. kann man so ein „Bar Kasse“ Konto führen.) Mittels Scripting – und dem richtigen Script – lassen sich so nun auch Paypal und die DKB Kreditkartenkonten abfragen. Dazu laedt man sich lediglich die neueste Jameica Version herunter und installiert das Hibiscus Plugin.

Anschließend muss man noch das jameica.scripting Plugin, HTMLUnit (wird zum Screen-Scraping der DKB und Paypal Webseiten verwendet) und die Scripte für Paypal und/oder DKB installieren – dafür gibt es zum Glück ein einzelnes Archiv, welches man hier herunterladen kann.

Das Archiv entpackt man – genauso wie das Hibiscus Plugin für Jameica – in den Plugins Ordner.

Nach dem Start von Jameica hat man unter „Datei->Einstellungen“ den Punkt „Scripting“, wo man Paypal und/oder das DKB Script aktivieren kann.

Für die DKB Kreditkarte erstellt man nun ein Offline Konto – als Bankleitzahl nimmt man die der DKB (12030000), als Kontonummer verwendet man die eigene Kontonummer und als Kundennummer verwendet man die Nummer der Kreditkarte. Hier kann man die mittleren Stellen der Nummer durch „*“ ersetzen – lediglich die ersten und letzten vier Ziffern der Kreditkartennummer müssen richtig angegeben sein.

Um Doppelbuchungen zu vermeiden, sollte unter „erweitert“ noch das automatische Gegenbuchen ausgeschaltet werden.

Das Konto kann anschließend über den Knopf „per Scripting synchronisieren“ abgefragt werden. (Leider nicht zentral mit den anderen HBCI Konten – aber immerhin.)

JUnit 4 bringt die (bessere) Syntax von assertThat über Hamcrest Matcher mit. Und nicht nur die Syntax ist besser, es gibt für viele Testfälle bereits „Matcher“, die das Leben erleichtern können.
Genauso kann einem das Leben aber auch erschwert werden: JUnit bringt eben nur ein Subset der Hamcrest Funktionalität mit. Den Rest kann man über die entsprechenden Hamcrest Bibliotheken hinzufügen. Und genau da gilt es nun aufzupassen: JUnit bringt eben bestimmte Versionen der Bilbiotheken mit – und dann kann es zu Konflikten kommen, die sich zur Test-Laufzeit erst zeigen:

org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf;
java.lang.NoSuchMethodError: org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf;
at org.hamcrest.text.IsEmptyString.(IsEmptyString.java:18)

Die Lösung ist dann JUnit ohne eigene Versionen von Hamcrest etc. zu verwenden (die „no-dependencies“ Version), und entsprechend die Abhängigkeiten selber aufzulösen.

Mit Maven sieht dann der Einsatz von JUnit, Mockito und Hamcrest z.B. folgendermaßen aus:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit-dep</artifactId>
  <version>4.8.2</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>1.8.5</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest-core</artifactId>
  <version>1.2.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest-library</artifactId>
  <version>1.2.1</version>
  <scope>test</scope>
</dependency>

Wie bereits in meinem anderen Eintrag zu Glassfish 3.1 beschrieben, ist seit der Implementierung der Servlet 3.0 Spezifikation in Glassfish 3.1 der Session Cookie standardmäßig auf „httpOnly“ gesetzt – dies kann Probleme mit einigen JavaScript Frameworks verursachen.

In dem web.xml Deploymentdescriptor kann dies umkonfiguriert werden, im glassfish-web.xml Descriptor ist dafür leider keine Möglichkeit vorgesehen. Weblogic, auch von Oracle mit BEA zugekauft, verhält sich dabei genauso, auch hier ist der Session Cookie auf httpOnly gesetzt – kann jedoch über den Weblogic spezifischen Deployment Descriptor unabhängig von der web.xml umkonfiguriert werden.

Und Glassfish 3.1 unterstützt nun auch ein Subset des Weblogic Deployment Descriptors um Weblogic kompatibel zu sein. (Vermutlich ist dies auch ein Grund, aus dem die Cookies httpOnly sind, um mit Weblogic konform zu sein.) Auch wenn es komisch ist, dass Glassfish selber keine Möglichkeit vorsieht das Verhalten im eigenen Deployment Deskriptor zu konfigurieren – über den Umweg des Weblogic spezifischen Descriptors geht es dann:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<session-descriptor>
<cookie-http-only>false</cookie-http-only>
</session-descriptor>
</weblogic-web-app>


Oracle hat heute den Glassfish 3.1 freigegeben – gleichzeitig als Open Source und als Oracle Glassfish Edition. Es gibt eine Menge neues, und dazu gehören auch neue Probleme.

Ich verwende Glassfish schon seit geraumer Zeit um mittels „Continuous Deployment“ für aktuell entwickelte Anwendungen eine separate Umgebung zu haben, in der ich und Kollegen testen können. Das ganze funktioniert mittels eine CI-Servers (Hudson Jenkins in diesem Fall), Maven und einem Deploy Plugin.

Auch mit Glassfish 3.1 funktionierte das Deployment prima – also hier war kein Update von Jenkins oder dem Deploy Plugin erforderlich. Auch die Anwendung startete – jedoch funktionierte nichts. Exceptions über ungültige Sessions gab es, auch Log-Einträge vom hier für Ajax eingesetzten DWR (Direct Web Remoting)

2011-02-28 18:57:13,037 [http-thread-pool-8090(2)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack.
2011-02-28 19:03:02,105 [http-thread-pool-8090(5)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack.

Dank Firebug etwas schlauem Rumraten und Probieren fand ich dann heraus: Glassfish 3.1 setzt Session Cookies per Default auf „HTTP Only“. Dazu gibt es bereits ein Ticket im Glassfish Tracker: GLASSFISH-15730

Es gibt nun mehrere Möglichkeiten für die nötige Kompatibilität mit Bestandsanwendungen zu sorgen:

Wird man die Anwendung zukünftig immer in einem Servlet 3.0 kompatiblen Container deployen, so kann man in der web.xml das Verhalten umkonfigurieren:

<web-app>
  <session-config>
    <cookie-config>
      <http-only>true</http-only>
    </cookie-config>
  </session-config>
</web-app>

Alternativ kann man bei DWR den CSRF Check deaktivieren, wovon ich jedoch abraten würde:

<servlet>
  <servlet-name>dwr-invoker</servlet-name>
  <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
  <init-param>
    <param-name>crossDomainSessionSecurity</param-name>
    <param-value>false</param-value>
  </init-param>
</servlet>

Die letzte Möglichkeit ist – in diesem Fall – auf DWR 3 umzustellen, hier wurde das Problem grundsätzlich gelöst, so dass nicht mehr per JavaScript auf den Session Cookie zugegriffen werden muss. (Siehe DWR-26) Leider gibt es von DWR 3 bisher noch kein Release, sondern lediglich vorab-Versionen.

Das Problem tritt übrigens auch mit Tomcat 7 auf, und nicht nur mit Glassfish 3.1 – ich frage mich, ob dies Verhalten am Ende sogar in der Servlet 3 Spezifikation vorgegeben ist.
Natürlich betrifft dies nicht ausschließlich DWR, sondern auch andere Anwendungen, die per JavaScript auf den Session Cookie zugreifen wollen/müssen.