I mentioned a small demo. in
Setting up policies for an Applet embedded in HTML & an Iced Tea JRE user commented that the demo. failed
for them. They refused permission to the applet (thereby limiting it to the sand-box) & were supposed to see
the green colored ‘this applet is sand-boxed’ page. Instead the applet completely failed and they saw a ‘gray space’
where the applet should have been.
I am WAGing that it was attempting to instantiate a File object that is the difference. I.E.
The Sun/Oracle JRE will allow it without problem, only throwing a security exception
when the applet attempts to create the JFileChooser. OTOH the Iced Tea JRE does not allow the
File to be created.
As such, this code should fix that problem. It moves the creation/adding of the
JEditorPane and installation of 1st
an ‘all else fails’ message, then the green colored ‘sand-boxed’ page, to before the new File(..) call.
My question is. Does this code ‘work as advertised’ for users with an Iced Tea JRE?
To test it:
- Visit the applet at
pscode.org/test/docload/applet-latest.html - Refuse the digitally signed code. This is very important to create the right
conditions to test the applet. - Observe/report whether the applet loads the green colored
sandbox.html. The sand-boxed
document will represent ‘success’ at fixing the bug.
Also of interest (what little there might be) is the homepage for the
Demo of Defensive Loading of Trusted Applets, which links
to the applet page(s), each of the HTML files displayed in the applet, and a ZIP archive containing the
source of the code & HTML, and an Ant build.xml so you can ‘do this at home, kids’.
Here is the new code.
package org.pscode.eg.docload;
import java.awt.BorderLayout;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import javax.swing.JApplet;
import javax.swing.JButton;
import javax.swing.JEditorPane;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JFileChooser;
import java.net.URL;
import java.net.MalformedURLException;
import java.io.File;
import java.io.IOException;
import java.security.AccessControlException;
/** An applet to display documents that are JEditorPane compatible.
This applet loads in a defensive way in terms of the security environment,
in case the user has refused to accept the digitally signed code. */
public class DocumentLoader extends JApplet {
JEditorPane document;
@Override
public void init() {
System.out.println("init()");
JPanel main = new JPanel();
main.setLayout( new BorderLayout() );
getContentPane().add(main);
document = new JEditorPane("text/html",
"<html><body><h1>Testing</h1><p>Testing security environment..");
main.add( new JScrollPane(document), BorderLayout.CENTER );
System.out.println("init(): entering 'try'");
try {
// set up the green 'sandboxed URL', as a precaution..
URL sandboxed = new URL(getDocumentBase(), "sandbox.html");
document.setPage( sandboxed );
// It might seem odd that a sandboxed applet can /instantiate/
// a File object, but until it goes to do anything with it, the
// JVM considers it 'OK'. Until we go to do anything with a
// 'File' object, it is really just a filename.
System.out.println("init(): instantiate file");
File f = new File(".");
System.out.println("init(): file instantiated, create file chooser");
// Everything above here is possible for a sandboxed applet
// *test* if this applet is sandboxed
final JFileChooser jfc =
new JFileChooser(f); // invokes security check
jfc.setFileSelectionMode(JFileChooser.FILES_ONLY);
jfc.setMultiSelectionEnabled(false);
System.out.println(
"init(): file chooser created, " +
"create/add 'Load Document' button");
JButton button = new JButton("Load Document");
button.addActionListener( new ActionListener(){
public void actionPerformed(ActionEvent ae) {
int result = jfc.showOpenDialog(
DocumentLoader.this);
if ( result==JFileChooser.APPROVE_OPTION ) {
File temp = jfc.getSelectedFile();
try {
URL page = temp.toURI().toURL();
document.setPage( page );
} catch(Exception e) {
e.printStackTrace();
}
}
}
} );
main.add( button, BorderLayout.SOUTH );
// the applet is trusted, change to the red 'welcome page'
URL trusted = new URL(getDocumentBase(), "trusted.html");
document.setPage(trusted);
} catch (MalformedURLException murle) {
murle.printStackTrace();
document.setText( murle.toString() );
} catch (IOException ioe) {
ioe.printStackTrace();
document.setText( ioe.toString() );
} catch (AccessControlException ace) {
ace.printStackTrace();
// document should already be showing sandbox.html
}
}
@Override
public void start() {
System.out.println("start()");
}
@Override
public void stop() {
System.out.println("stop()");
}
@Override
public void destroy() {
System.out.println("destroy()");
}
}
Here is the output on
java.stderr(one half of the equivalent of the Java console – the other half isjava.stdout, which is empty in your case):So, it looks like your applet code is not even loaded if I press Cancel in the dialog box.
I think there is nothing you can do here from the Java side – maybe using another signing procedure or starting the applet by JNLP would help. Or filing a bug report on IcedTea.
To demonstrate this, I created a real simple applet by omitting everything critical from your applet:
I compiled this and modified your HTML file to use this instead, and it gives totally the same symptoms.
It seems IcedTea has redefined what to do when the user presses cancel. To be fair, the buttons in the dialog box are “Run” and “Cancel”, not “Run with all permissions” and “Run sandboxed”.
(In Sun’s dialog there are the same buttons, but in effect they mean something else than asked.)