0

I am using a sandboxed applet (Java 8u25) in a webpage which is trying to connect to another port on the same server.

In older Java-Version (pre 8) this worked without any problems.

With java 8 this kind of access is considered a cross-domain access and thus tries to load the crossdomain.xml on the target port.

But in my case this port does not handle HTTP (our own binary data protocol) and does not answer properly or at all to the request.

It seems now that the applet has no timeout for that situation and thus the request remains stuck in the CrossDomainXML.check() call.

Here is a stack from a thread dump of the stuck applet:

at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
- locked <0x058c2288> (a java.io.BufferedInputStream)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
- locked <0x058c2328> (a sun.net.www.protocol.http.HttpURLConnection)
at sun.net.www.protocol.http.HttpURLConnection.access$200(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivileged(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
- locked <0x058c2328> (a sun.net.www.protocol.http.HttpURLConnection)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at sun.plugin2.applet.SecurityManagerHelper.checkURLPermissionHelper(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.URLtoSocketPermission(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at myCode calling new URL("http://...").openConnection().connect();

Is there a way to set the connection-timeout or somehow in other ways influence the crossdomain.xml-check to fix this problem?

Edit: I just noticed something even more evil: Once one call gets stuck at this point (even if i kill the thread), NO further calls can be made successfully in any thread. I believe it is because a certain lock is held and stays blocked even when interrupting or stop()ing the stuck thread. (interrupt() seems to have no effect at all.)

Also setting the global connection-timeout like this is not allowed in sandboxed applet:

System.setProperty("sun.net.client.defaultReadTimeout", "2000");
System.setProperty("sun.net.client.defaultConnectTimeout", "2000");

But it might be worth a try to set them via VM parameter from the outside.

Frederic Leitenberger
  • 1,949
  • 24
  • 32

1 Answers1

0

I am using a sandboxed applet (Java 8u25[+/-]) in a webpage which is trying to connect to another port on the same server.

This is not possible anymore.

Oracle changed the behaviour, (but, as always) I found no message on this topic on their site.

It looks like it came effective the same day as of the deployment of Java 8 Update 25. But it seems to have an effect on older Java-Install called by the new Plugin, too.

You have to change (or introduce) permissions, to all-permissions. And keep in mind that this can be defined (as sandbox) in the applet call script, jnlp-file, Manifest, Applet-Viewer, ...

springfeld
  • 89
  • 8