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 is java.stdout, which is empty in your case):
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:604)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
... 2 more
Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
at sun.applet.AppletPanel.run(AppletPanel.java:380)
at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
at sun.applet.AppletPanel.run(AppletPanel.java:430)
at java.lang.Thread.run(Thread.java:636)
java.lang.Exception: Applet initialization timeout
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
java.lang.RuntimeException: Failed to handle message: handle 60822154 for instance 2
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:660)
at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
Caused by: java.lang.Exception: Applet initialization timeout
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
... 2 more
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:
package org.pscode.eg.docload;
import java.awt.FlowLayout;
import javax.swing.*;
public class Example extends JApplet {
JLabel label;
public void init()
{
System.out.println("init()");
SwingUtilities.invokeLater(new Runnable(){public void run() {
label = new JLabel("inited.");
getContentPane().setLayout(new FlowLayout());
getContentPane().add(label);
}});
}
@Override
public void start() {
System.out.println("start()");
label.setText("started.");
}
@Override
public void stop() {
System.out.println("stop()");
label.setText("stopped.");
}
@Override
public void destroy() {
System.out.println("destroy()");
label.setText("destroyed.");
}
}
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.)
For reference, I can confirm @Paŭlo Ebermann's results using IcedTea 1.9.7 on Ubuntu 10.04:
$ java -version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1~10.04.1) OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)
appletviewer shows the expected sandbox and the fllowing diagnostic output. Firefox on Ubuntu offers only Run (trusted) or Cancel (nothing).
$ appletviewer http://pscode.org/test/docload/applet-latest.html
Warning: Can't read AppletViewer properties file: … Using defaults.
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302)
at java.lang.System.getProperty(System.java:669)
at javax.swing.filechooser.FileSystemView.getHomeDirectory(FileSystemView.java:397)
at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:282)
at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:153)
at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:155)
at javax.swing.JComponent.setUI(JComponent.java:651)
at javax.swing.JFileChooser.updateUI(JFileChooser.java:1781)
at javax.swing.JFileChooser.setup(JFileChooser.java:374)
at javax.swing.JFileChooser.(JFileChooser.java:347)
at javax.swing.JFileChooser.(JFileChooser.java:330)
at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
at sun.applet.AppletPanel.run(AppletPanel.java:436)
at java.lang.Thread.run(Thread.java:636)
start()
stop()
destroy()
On Mac OS X, Safari 5.05 produces the expected results; and appletviewer produces comparable, but not identical, output.
$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-9M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
$ appletviewer http://pscode.org/test/docload/applet-latest.html
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.io.FilePermission . read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:731)
at javax.swing.JFileChooser.setCurrentDirectory(JFileChooser.java:548)
at javax.swing.JFileChooser.(JFileChooser.java:334)
at javax.swing.JFileChooser.(JFileChooser.java:316)
at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
at sun.applet.AppletPanel.run(AppletPanel.java:424)
at java.lang.Thread.run(Thread.java:680)
start()
stop()
destroy()
来源：https://stackoverflow.com/questions/5356850/does-this-applet-work-in-an-iced-tea-jre