🚀 go-pugleaf

I know I'm wrong, I just want someone to TELL me I'm wrong - and to show
me why.

I'm having trouble getting a response to the following observation that
I've posted about a few times.
It appears to me that if you write APPLETS  in Swing, then even if you
DON'T attempt to escape the sandbox, you still have to take on all the
painful, browser-specific security measures (such as applet-signing and
the inclusion of calls to various incompatible security packages.) And I
find
this outrageous, if it's really true.

I'm forced to this conclusion by the fact that I decided some time ago
that the whole security thing was a mess, and I decided to take every
measure necessary to avoid it for as long as I could. Functionally, my
applet did not require me to escape the sandbox to do its job.

Because I had a background in Swing application development, I decided
to implement my applets in Swing. I discovered that the architecture of
Swing is such that ANY applet (that fires an event - and what
non-trivial applets don't?) MUST exceed the constraints normally placed
on applets, and therefore, you cannot deploy applets written in Swing
without having to take these extra security measures.

I posted the following angry  rant to JDC's GroupReader/Toolbar. To date
it has generated (0) responses. There are two short messages, followed
by my (probably erroneous) reasons for
stating the above.

kbarclay
kebarcla@hotmail.com


Path: developer.java.sun.com!unseng
From: unseng
Newsgroups: swing
Subject: Swing: checked access to system event queue.
Date: Mon Aug 03 13:41:15 PDT 1998
Organization: Java Developers Connection
Message-ID: <289024973$815@developer.java.sun.com>
JDC-state: closed
JDC-points: 1
JDC-notify: true
NNTP-Posting-Host: developer.java.sun.com

Hi:


Does Anyone know that what is that means? "Swing: checked access to
system event queue."
That is generated by initialization of my JApplet. Is that related to
signed and unsigned applet?
My program also threw a AppletSecurityException as
"checkawteventqueueaccess". This exception is
thrown when the program tried to pop-up a dialog box.

The Dialog box is created by below code:

 int userAnswer = JOptionPane.showInternalConfirmDialog(
    this,
    "Save the changes to this window?",
                           "Save Changes",
                           JOptionPane.YES_NO_CANCEL_OPTION,
    JOptionPane.WARNING_MESSAGE);

Is anyone known how to work around with it???

Thanks in Advance

Seng




Answers
======


** From: heyhey
Replied: Tue Aug 04 00:04:08 PDT 1998

This is known behaviour.
Read swing's file

  CHANGES.TXT

 section

==============
 Applet Changes
==============


** From: kbarclay
Replied: Tue Aug 04 09:56:36 PDT 1998

heyhey suggests the old "hack" of putting

applet.getRootPane().putClientProperty("defeatSystemEventQueueCheck",
Boolean.TRUE);

in your applet code to subdue the security exceptions. I found this 100%
ineffective in solving the
security problems; in fact, it doesn't even quiet the salacious little
warning that says:

"Swing: checked access to system event queue."

Maybe I'm not placing it in the correct location? I tried the init
method, and ...and  the little test applet
I put this in is only a dozen lines long, so there aren't many other
places to put it.

This applet comes with the Swing release: it's called SwingApplet.java.
I pared it down to a bare
minimum and pasted it below so you can see that this applet really does
almost nothing except
put a button onto the page. Yet when you put the little applet on a
webserver and deploy it, when
you stab the little button, you get (in IE4.0) the stack trace that I've
pasted below the code.
 (It runs fine in NS4.05/preview release.)

Since IE4 was written by the Evil Empire I looked in The Java Class
Libraries Vol 1 by Chan and Lee
to see what behavior is specified in these circumstances. From what Sun
says should be happening,
it appears that Microsoft's VM is doing what it should, and Netscape's
is failing to throw an
exception. On page 1485 it says:

"Gaining a reference to the system event queue has security
implications. This is because with
the reference, you can read the queue's contents or post events to it."

That makes sense. You obviously can't have any old applet posting events
to your event queue.

Let me see if I understand correctly the implications of this.

1) Swing is written in such a way that, as a matter of fact, when an
event is fired, it needs to get a
reference to the event queue.
2) Getting such a reference is a *privileged* operation - like making a
socket connection to a
computer other than the applet's host, or reading/writing files on the
user's computer.
3) Therefore, any applet written in Swing, no matter how trivial,
requires that one go through all
the contortions that are necessary when you're trying to produce an
applet that can "break out of
the sandbox."

Because this is insane, I KNOW I must be wrong.

I just know that any day now, someone  at the forefront of Swing
development is going to tell me that
 I can write applets in Swing that don't try to escape the sandbox
without having to go through the
SOLID NIGHTMARE of having to sign my applets using two (or is it three?)
incompatible applet
signing tools, and/or download two incompatible sets of security classes
(Microsoft's
com.ms.Security classes from SDK 3.0, or Netscape's security classes)
and then keep two
completely separate sets of code for each of the two predominant
browsers.

It doesn't seem reasonable to me that my users can't just hit a page
with an applet embedded
in it and have it download and run. It's not reasonable that I have to
go through Security Hell in
my applet development process if I'm not trying to escape the sandbox.

My users should not have to download a five-meg plugin to run my applet.
They shouldn't have
to copy jar files to some directory that's visible to their browser, or
tweak security settings in
various dialogs in their browser. And they are, as a matter of fact,
evenly divided between
IE4 and Netscape! To me that means avoiding RMI and any other package
Microsoft doesn't
want to support. Users don't care if you use sockets and streams or if
you use RMI. They DO
care if they have to download a giant plugin before running your applet.

I'm running Swing 1.0.3/jdk 1.1.6 on an NT Box.
If anyone knows how to run the following 12 lines of code in IE4 without
throwing security
exceptions, please email me or post.

Thanks,

Ken
kebarcla@hotmail.com

/*
 * @(#)SwingApplet.java 1.9 98/02/23
 */

import java.awt.*;
import java.awt.event.*;
import java.net.*;
import java.applet.*;
import com.sun.java.swing.*;

/**
 * A very simple applet.
 */
public class SwingApplet extends JApplet {

    JButton button;

    public void init() {

        getRootPane().putClientProperty("defeatSystemEventQueueCheck",
Boolean.TRUE);

        getContentPane().setLayout(new FlowLayout());
        button = new JButton("Hello, I'm a Swing Button!");
        getContentPane().add(button);
    }

    public void stop() {
        if (button != null) {
            getContentPane().remove(button);
            button = null;
        }
    }
}

The stack trace is:

com.ms.security.SecurityExceptionEx[com/sun/java/swing/SystemEventQueueUtilities.initSystemEventQueue]:

 Event queue access denied.
 at com/ms/security/permissions/UIPermission.check
 at com/ms/security/PolicyEngine.deepCheck
 at com/ms/security/PolicyEngine.checkPermission
 at com/ms/security/StandardSecurityManager.chk
 at com/ms/security/StandardSecurityManager.checkAwtEventQueueAccess
 at java/awt/Toolkit.getSystemEventQueue
 at com/sun/java/swing/SystemEventQueueUtilities.initSystemEventQueue
 at com/sun/java/swing/SystemEventQueueUtilities.postRunnable
 at com/sun/java/swing/SwingUtilities.invokeLater
 at com/sun/java/swing/RepaintManager.queueWorkRequest
 at com/sun/java/swing/RepaintManager.addDirtyRegion
 at com/sun/java/swing/JComponent.repaint
 at java/awt/Component.repaint
 at java/awt/Component.repaint
 at com/sun/java/swing/plaf/basic/BasicButtonListener.stateChanged
 at com/sun/java/swing/AbstractButton.fireStateChanged
 at com/sun/java/swing/AbstractButton$ButtonChangeListener.stateChanged
 at com/sun/java/swing/DefaultButtonModel.fireStateChanged
 at com/sun/java/swing/DefaultButtonModel.setRollover
 at com/sun/java/swing/plaf/windows/WindowsButtonListener.mouseEntered
 at java/awt/Component.processMouseEvent
 at java/awt/Component.processEvent
 at java/awt/Container.processEvent
 at java/awt/Component.dispatchEventImpl
 at java/awt/Container.dispatchEventImpl
 at java/awt/Component.dispatchEvent
 at java/awt/LightweightDispatcher.retargetMouseEvent
 at java/awt/LightweightDispatcher.setMouseTarget
 at java/awt/LightweightDispatcher.processMouseEvent
 at java/awt/LightweightDispatcher.dispatchEvent
 at java/awt/Container.dispatchEventImpl
 at java/awt/Component.dispatchEvent
 at java/awt/EventDispatchThread.run
Swing: checked access to system event queue.
Microsoft (R) VM for Java (tm), 4.0 Release 4.79.0.2339

POSTSCRIPT:

In the readme.txt file that comes with SwingApplet.java, it says:

"When you successfully run the applet, you might see a message about a
security exception.  It starts like this:

   sun.applet.AppletSecurityException: checkawteventqueueaccess

Please ignore this exception."

And I most willingly DO ignore the exception when it's put out by the
appletviewer. When I actually
try to do stuff in a more sophisticated applet, though, and try to run
it off my webserver, it throws
the exception above and chokes.