4

A client noticed that one of our java applets wasn't working anymore. However, we are not able to tell what the problem is.

Specs

The webapp is tiparlo. It is used to record and organize spoken language and mainly used at schools to train language and store for evaluation later. The app consists of an HTML interface, which is managed by JavaScript. The sound playing and recording is done via an in-house developed java applet. As you can see on the test-page, the applet itself is in a working state.

In tiparlo however, the applet (further called soundrecorder) doesn't have a preloaded sound file. Since tiparlo consists of multiple sound files, JavaScript tells soundrecorder what file to play. For instance, if you want foo.ogg to be played, javascript tells soundrecorder to play http://url/path/foo.ogg.

This worked for some years now but not anymore.

Bugtracking

The problem is that it does work under certain conditions. For instance, it works on our local dev-machines, and on our public test-env. It just ceased to work for our clients.

Working example: http://test.s2.olefa.com/cgi-bin/apps/tiparlo?projectid=3&mode=viewer
Non-working example: http://www.ecoles-dudelange.lu/cgi-bin/apps/tiparlo?projectid=1594&mode=viewer

Some useful facts:

  • both examples are running on the same server

  • the java applet, the js code, the html parser and the source code are shared resources. Hence, both examples are running the exact same code

  • the relevant files to the problem are: soundrecorder.js and jrecord.jar. The play command is in soundrecorder.js:line 112

What we know so far

  • Browsers react differently to the non-working example. Safari/Mac plays everything right. Safari/Win however freezes on play. Firefox 4 doesn't play anything at all. Firefox 3.5/Mac does everything right again. However Firefox3.5/Win doesn't play anything at all. IE9 has the same problem. Same goes for Chrome. Opera crashes outright and needs to be restarted. We haven't yet found a browser on linux that works on the non-working example. To clarify: the working example works with all browsers on all platforms, except for Safari/Win (meh). UPDATE: It depends on the java version. With java 6.20, all the non-working example works on all browsers. With java 6.24, only the working example works.

  • We tried using the alternative server-url for our non-working example (webX.sX.olefa.com), which is similar to the working example. This attempt failed.

  • We tried using relative paths for soundrecorder (e.g. /path/foo.ogg).

  • We tried updating Java to the latest version.

  • We tried accessing the applet differently.

  • We had a similar problem 6 months ago, that was caused by a java update. We tried the non-working example on a VM with an older java-version. It works. However, we suspect that java alone is not the culprit here since the same java-version/browser works on the working example.

  • Soundrecorder only refuses to play files that are loaded dynamically via JS. If it loads a file on init, there is no bug.

  • The applet itself is loaded. You can make it visible by giving it a width/height. I suspect that there is a problem in the java/js intercommunication (js is telling java what to play but the communication is faulty?). However I can't confirm this as of yet.

Generally speaking, we can't find out why the exact same code running under the exact same conditions works on one site, but doesn't on the other.

Solution

The solution is part of a comment. The problem and solution can be found here. Thanks to Ryan for pointing us in the right direction.

Community
  • 1
  • 1
Mike
  • 2,567
  • 3
  • 23
  • 35

1 Answers1

4

I'm using FF4 on windows (Java 1.6.0_24) and was able to see the applet at http://www.ecoles-dudelange.lu/cgi-bin/apps/tiparlo?projectid=1594&mode=viewer.

However, when I clicked on the big blue play icon at the bottom of the page all the smilies in the pane above the button seem to glow - 'mexican wave' style. Impressive :)

I did peek into the java applet console and noticed the following errors once the button was clicked:

network: Cache entry not found [url: http://www.ecoles-dudelange.lu/resources/audio/_tiparlo_1594/ismael_20110405_11-17-47_3129344.ogg, version: null]
network: Connecting http://www.ecoles-dudelange.lu/resources/audio/_tiparlo_1594/ismael_20110405_11-17-47_3129344.ogg with proxy=DIRECT
network: Cache entry not found [url: http://85.119.157.43/crossdomain.xml, version: null]
network: Connecting http://85.119.157.43/crossdomain.xml with proxy=DIRECT
network: Connecting http://85.119.157.43:80/ with proxy=DIRECT

java.security.AccessControlException: access denied (java.net.SocketPermission 85.119.157.43 resolve)
    at java.security.AccessControlContext.checkPermission(Unknown Source)
    at java.security.AccessController.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkConnect(Unknown Source)
    at sun.plugin2.applet.Applet2SecurityManager.checkConnect(Unknown Source)
    at sun.net.www.http.HttpClient.New(Unknown Source)
    at sun.net.www.http.HttpClient.New(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
    at java.net.URL.openStream(Unknown Source)
    at lu.educdesign.audio.gui.JRecordApplet.load(Unknown Source)

...

The URL http://85.119.157.43/crossdomain.xml loads an html page that redirects to http://confixx.s2.olefa.com prompting for a username/password.

Maybe there's a good explanation for this, but it seems to me, prima facie, that this could be a problem

Ryan Fernandes
  • 8,238
  • 7
  • 36
  • 53
  • confixx sounds like a config error. However, I am able to access the file with the browser. Will look into that. At least we now have a valid lead. Thx mate. – Mike Apr 29 '11 at 09:21
  • >"However, I am able to access the file with the browser." - try clearing your cookies and see if you can still access it. – Ryan Fernandes Apr 29 '11 at 09:23
  • Yes, still works. But with your help, I have found a similar problem here: http://stackoverflow.com/questions/4135138/access-denied-java-net-socketpermission-127-0-0-18080-connect-resolve. The symptoms all match. – Mike Apr 29 '11 at 09:41
  • I'd be interested to know which of the 4 workarounds suggested for CVE-2010-3560 solved the issue for you. – Ryan Fernandes Apr 29 '11 at 10:38