Using Applets to Play Outside of the Sandbox

<p>Imaging Experts has a solution to allow you to get out of the sandbox via signed applets the right way.

The problem they ran into was that they were getting the following message when trying to write to a file, even with a signed applet:

java.security.AccessControlException: access denied (java.io.FilePermission C:imagesimg1.tif read)
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.checkWrite(Unknown Source)

The solution was found via google:

I figured I would use the JavaScript method just to set some properties in the Applet. I would then create a separate thread that could be responsible for listening to changes in these fields, and calling the openFile method on behalf of the JavaScript.

PLAIN TEXT

JAVA:

Thread javascriptListener = new Thread()
{
public void run()
{
while (true)
{
if (gJavascriptCalled)
{
gJavascriptCalled = false;
openFile(gJavascriptFilename);
}
try
{
sleep(JAVA_SCRIPT_POLL_INTERVAL);
}
catch (Throwable t)
{
t.printStackTrace();
}
}
}
};
javascriptListener.start();

Ah the fun people have to go through to get past the sandbox.

5 Comments »

Comments feed TrackBack URI

I’m gonna bookmark this page just in case! I remember doing some stuff with signed applets a couple years back, an absolute nightmare…

Comment by Thomas Messier — October 17, 2006

I had same problem several months ago trying to print barcode labels from a web application and that was the only way to avoid the security warning everytime, I found it on Sun forums (had to dig a lot tho).

Comment by JacSoyYo — October 17, 2006

MashProxy is another Java based solution to extend the browser, but with cross-domain capabilities: http://mashproxy.com/
The problem with Java is that once you manage to pry the door open, things quickly become dangerous. It’s hard to achieve a controlled amount of openess and it’s easy to create additional security risks.

Comment by Julien Couvreur — October 17, 2006

I met the same thing about 2 years ago. And many of my JavaScript calls are restricted so the calls need to be asynchronized. But my JavaScript calls just should be a syncrhronous call. So callbacks are used, and the Applet is now became a server! And JavaScript became a browser! Both are in asynchronous mode! What about there are two restricted calls should work together with a middle JavaScript DOM action and before/after actions? You must block and indicate the user in JavaScript side. Lots of other problems came to me contributing paints at that time.

I just remember that nightmare of integrating Java Applet and JavaScript together. So I recommend you NOT to rush to such “JavaScript in Applets – Getting Out of the Sandbox technology” until you are ready for nightmares. Actually I recommend NO Java Applet + JavaScript.

Comment by Zhou Renjian — October 17, 2006

bggmoqcak

tluoqbzblo ykgaujhdxi gdzmxmisa dglptfxldc

Trackback by usdubxllc — October 21, 2006

Ajax Questions and Answers

Caching and dynamic views
My client does not want to change his cache settings on IE and I'm trying to figure out a way to dynamically update a view each time it is visited. I...

IE 8 Crashing Problem
Hello Everyone, Here\'s the situation: two iSeries boxes - Dev and Prod both V5R4M0 We\'re using AJAX to dynamically load content using a tabbed...

JQuery Function Not Defined?
[div]Hi there,[/div] [div][/div] [div]I\'m trying to set a php session variable from a radio button. The idea is that a jquery function is called...