Copy/Paste not working in a signed Applet

Question

I've a signed applet (which verifies correctly with jarsigner) that for some reason will not allow copy and paste from the system clipboard into a JTextField despite the documentation telling me that it is supposed to work for signed applets.

Furthermore, I've other applets which are signed with the same keyfile that do let me copy and paste text. I have searched high and low on the internet and can't seem to find any clues. What is making me pull my hair out is that there seems to be no way to debug this (no output in the console - no thrown exceptions).

Does any one have any ideas on how I can debug this to find out why Java doesn't like this particular applet?

Many thanks for any suggestions!

Herat

Answer 1

Well, it turns out with the release of the Java Plug-in 1.6.0_24 in February 2011, copy and paste from the system clipboard was deemed a security hole and disabled. You can copy and paste BETWEEN applets. But if you try to use something from your main clipboard, it can't be copied in.

So there are a couple of options for a workaround. You can roll back to an earlier version of the plug-in. That will work, but chances are all future releases will still keep copy and paste disabled, so you'd never be able to upgrade.

The other alternative is to provide a custom java security policy file which enables access to the system clipboard again.

First locate your local Java Security Policy file. The file is named java.policy and should be in the lib\security folder of your Java installation. On Windows 7, it can be found at C:\Program Files (x86)\Java\jre6\lib\security. Copy this file to your home folder (ex. C:\Users\Kyle). Rename the file to .java.policy (note the period at the beginning). Edit the file in a text editor. Locate this line of text:

// "standard" properies that can be read by anyone

Add the following line just below it like so:

// "standard" properies that can be read by anyone
permission java.awt.AWTPermission "accessClipboard";

Save the file. Close any open browsers and ensure that Java is not running before testing.

source: http://blogs.oracle.com/kyle/entry/copy_and_paste_in_java

Selfesteem

Thank you - I have seen this, but I was under the impression that it had been disabled for UNSIGNED applets only (according to my research). Signed applets should still work - and another signed applet is currently allowing copy and paste. Any more ideas? – Herat

What version of java plugin are you using? What browser are you testing this with? Do you get a prompt to allow/disallow the copy/paste service? Have you checked out the clipService demo? pscode.org/jws/api.html#cbs – Selfesteem

This is a applet which is deployed across many JVMs in several corporations. I currently run 1.6.0_26 and I do not get prompted to allow/disallow the copy/paste service. If I add code to handle accessing the system clipboard, it allows me and I can paste into the field. – Herat

@user1098932: I have the same problem. I added accessClipboard to my policy. I signed my applet too (but it is self-sign, not trusted-sign). I think it will be run ok, but Access denied error still occurs. Some blogs told me that self-sign applet can work out side sandbox on develop environment (in that case it's my computer). Can you tell me it's true? – Appropriate

Why it says properies not properties, and still properies in java.policy file – Volcanic

Answer 2

Besides Dennis' overview, see Copy in sand-boxed app. in 1.6.0_24+ at the OTN.

While Ctrl-c copy no longer works by default, it is possible to add the functionality back in for any applet run in a 'Next Generation' Java Plug-In. Since Java Web Start existed, JWS provided sand-boxed copy via. the JNLP API's javax.jnlp.ClipboardService, & since Sun 1.6.0_10, & the next gen. plug-in, embedded applets can be deployed using JWS & can access the JNLP API.

See also

• http://pscode.org/prop/js.html. Direct link to the test applet used in that thread. It offers copy ability in a sand-boxed applet. If it works on the problem machine (browser, set-up ..whatever) you should be able to rework it to offer (unprompted) paste in a signed applet.
• Frame based Demo. of the ClipboardService, with source and build file.

Resale

wondering (as well as @user1098932) - why would the security fix affect signed applets/webstartable? Me missing the point, maybe - which I think is to allow stuff which is disabled in sand-boxed contexts? – Botany

@Botany The problem is a complex & subtle one, which I do not claim to fully understand. It was best explained in Sami Koivu's blog entry on Multiple Java Clipboard Vulnerabilities for Applets (linked from the OTN thread). Unfortunately, what seems to be missed by the Kyle blog entry, as well as Dennis' answer (as well as most people reading this thread, seemingly) , is that it is fixable using the ClipboardService. :( – Resale

yeah, aware of Sami's blog and ClipboardService - but he's talking about potentially harmful Java code from an untrusted source gains read/write access to system clipboard (vulnerabilities 1&2), and full privilege escalation to do anything with the privileges of the user .. and his comment on a requirement for the c&p fits my expectation I imagine if you can sign your applet it will resolve the issue My potentially naive :-) point would be that iff I go through all the trouble of signing, I don't have to worry about security restrictions at all – Botany

Even a trusted applet will (normally) have a sand-box. Things like System.exit(n) should not be called in an applet, ever. As to what problems this might cause due to a trusted applet using the clip-board exactly, I must concede I don't know. The best explanation I can offer is that perhaps they are taking the attitude - Better safe than sorry. – Resale

Answer 3

I'm not sure why, but the JTextField object I'm using doesn't seem to be properly connected to the key events (maybe because I added a FocusListener?) - but adding the following code:

    searchTextField.addKeyListener(new java.awt.event.KeyListener() {
        public void keyPressed(KeyEvent e) {
            //System.out.println("KEY:"+e);
            if (e.getKeyCode() == 86 && ((e.getModifiers() & KeyEvent.CTRL_MASK) != 0)) {
                java.awt.datatransfer.Clipboard clipboard = java.awt.Toolkit.getDefaultToolkit().getSystemClipboard();
                java.awt.datatransfer.Transferable clipData = clipboard.getContents(clipboard);
                String s;
                try {
                    s = (String)(clipData.getTransferData(java.awt.datatransfer.DataFlavor.stringFlavor));
                } catch (Exception ex) {
                    s = ex.toString();
                }
                searchTextField.setText(s);
            }
        }
        public void keyReleased(KeyEvent e) {
        }
        public void keyTyped(KeyEvent e) {
        }
    });

...allows me to paste into the field.

Herat

Answer 4

1. Take a backup of java.policy which is at (Ex: C:\Program Files (x86)\Java\jre7\lib\security)

2. Look for line in java.policy file // "standard" properies that can be read by anyone

3. Then modify java.policy and add as below

// "standard" properies that can be read by anyone permission java.security.AllPermission;

Corroborate