Access System clipboard content - not a new issue in the based system applications (OS), but it is rather complicated with the based Web applications. Although jsB@nk introduced a code can access clipboard data but it still need the middle application - Flash.

Today, within this article, the author will help you better understand this operation with the facts, reality and solutions for each issue. Please view this article for more.

• Demo
• Enlarge
• Reload
• New window

I am developing an API written in JavaScript for a project which requires the ability to copy data to, and retrieve data from, a clipboard within a web browser. A simple/common problem definition - but due to tight browser security, finding a solution is a bit of a nightmare. This article outlines and discusses a number of approaches for implementing a clipboard feature into your JavaScript applications.

The Ideal JavaScript Clipboard Interface

The concept of the "clipboard" is simple; it is essentially a place for storing and retrieving a single unit/piece of cloned data. The code snippet below describes this clipboard concept in terms of a JavaScript interface.

Clipboard = {
    copy : function(data) {
        //... implemention ... 
    },
     getData : function() {
        // ...  implementation ... 
     }
};

A simple concept, a self explanatory interface. However, the description above is vague; it does not state where "the clipboard" resides, nor does it mention if there can be more than one clipboard.

Multiple Clipboards

Unfortunately there can be more than one clipboard present. There is one "System clipboard" present when a user is logged into their profile/account (some strange people might install/configure some features on their OS to support multiple system clipboards). Ideally, all applications should use the system clipboard when copying and pasting so its users can copy and paste between all applications. However this is not always the case. For example, Cygwin uses its own clipboard for Cygwin applications and unless the user explicitly turns on a clipboard integration option, the user cannot copy and paste between Cygwin applications and non-Cygwin applications.

The Web's Sandbox Environment

Web applications run in a sandbox environment to prevent malicious scripts from infecting a visitor's computer. The sandbox environment restricts access to system resources, such as the file system, and unfortunately, the system clipboard. Check out this article for one example why the system clipboard is a restricted resource. Fortunately restrictions for accessing the system clipboard can be overcome. There are many approaches for accessing the system clipboard - each approach has its own trade-offs.

Internet Explorer's clipboardData Object

Microsoft's Internet Explorer family makes life very easy to access the system clipboard. To set the system clipboard's text, just use the object. Here is an example:

var didSucceed = window.clipboardData.setData('Text', 'text to copy');

To access the system's clipboard data (in a textual format) you simply invoke:

var clipText = window.clipboardData.getData('Text');

The first time the clipboardData object is accessed IE will prompt the user to allow the script to access the system clipboard (note: if you run the script locally IE does not bother with the confirmation and automatically allows it). IE version 6 and below will not bother asking the users (unless they have some non-default security features set to a "high level"). We cannot assume that users will choose to allow the script to access the system clipboard. If they decline, the clipboardData.setData method returns false. Unfortunately the clipboardData.getData method is vague: as it returns an empty string if the user chooses to decline. This is ambiguous since the system clipboard's contents could actually be empty! Ideally it would return null. You could either always assume that empty string is a signal for failure to access the clipboard and try use a different method (read on), or you could attempt to verify that it was a failure:

var clipText = window.clipboardData.getData('Text');
if (clipText == "") { // Could be empty, or failed
	// Verify failure
	if (!window.clipboardData.setData('Text', clipText))
		clipText = null;
}

Note: the verification method will not display two prompts, since the first prompt will be remembered for the session.

A Sketchy Work-around: The Flash Copy Hack

Jeffrey Larson came up with a nifty solution using Adobe Flash. To copy text to the system clipboard a small flash object is embedded into the document by manipulating the DOM, and the text to be copied is passed as a parameter to the embedded object. The Flash program then takes this text and copies it to the system clipboard via the Flash API. This was a security hole in Flash up-to and including versions 9, and was patched in version 10 so that unsolicited access to the system clipboard is denied. That is, Flash requires users to physically trigger the ActionScript clipboard code via a mouse click in order to grant access.

There still exists a workaround using that is supported by Flash 9 and 10. A small JavaScript library called ZeroClipboard exploits Flash, and fools the users, by placing invisible Flash movies over button elements. Whenever a user clicks on these invisible flash movies, ZeroClipboard successfully copies text to the system clipboard since the access is technically not "unsolicited." This is a bit cheeky, some people are calling this process "click jacking." It could be seen as a security flaw, and later Flash releases might put an end to this clipboard exploitation mayhem once and for all - who knows.

Using ZeroClipboard will only allow copying of text to the system clipboard on mouse-clicks. It does not allow access in any other contexts, such as timers, or CTRL+C keyboard events. It is a specific solution intended for Copy buttons.

One drawback is that this option does require the browsers to have the adobe flash plugin installed. So detection of Flash support is essential. Adobe has released a simple-to-use detection kit which would do the trick. Another simple one can be found here.

Flash version 9 has a bug in Linux systems where Web browsers are unable to support transparency for embedded Flash movies. Thus ZeroClipboard is not suitable on clients with this setup.

ZeroClipboard should be named ZeroSysCopy or something similar since it only provide unidirectional access to the system clipboard. I attempted to pursue a bidirectional implementation, but the ActionScript API does not provide any way of clipboard retrieval due to security risks. Adobe's ActionScript API for the Flex environment does provide ways of getting to the system clipboard, but only on paste events from a paste button click on a context menu, or paste commands like CTRL+V.

Using Java Applets

Jeffrey Larson's Flash copy hack got me thinking: what about taking a similar approach using Java applets instead of Flash movies. The beauty of Java is that it can communicate directly with JavaScript, thus can support both copy and paste operations. This is possible via a technology called Liveconnect. This solution has some pricey trade-offs though.

Liveconnect

Netscape developed an API called NP API (Netscape Plugin API) which is a cross browser plugin architecture supported by all major browsers except IE today (although some IE browsers do support it - IE's equivalent is ActiveX). Liveconnect is one way to implement NP API-based plugins using JavaScript and Java. It was first supported in Netscape 4. A plugin could implement and return an instance to a Java class. The public methods exposed by this class was the scriptable interface for the plugin. The class could be called from JavaScript and even from other Java applets running within the page with the browser marshalling the calls between the various contexts. (see http://en.wikipedia.org/wiki/NPAPI#LiveConnect). The technology has matured since then and is still supported by Mozilla browsers, and Opera. Webkit does not seem to support it anymore.

Some browsers, such as Firefox, do not ship with a Java Virtual Machine plugin, since it "bloats" the browsers download size. So like the Flash hack, it depends on a plugin, which is a bit of a concern since the JVM plugins are relatively large to download.

Sun has respecified and reimplemented the Liveconnect technology as of version 6 update 10, which to my understandings just means that it is faster, more reliable and contains a bunch of extra features not needed for the purposes of some simple clipboard code.

Implementation

There are many issues and quirks with this technology. Luckily the code will be very small and simple for the clipboard. Most browsers support the ability to directly use Java inside of JavaScript, but some browsers have issues with some things such as creating new class instances. A more reliable approach would be to store the Java clipboard code into an applet.

Try the demo here. Click here for the applet source. Note that it only works on some browsers, and most probably not on IE.

Hopefully the demo code is self-explanatory. In order to break out of the JVM sandbox environment java.security.AccessController.doPrivileged is used. Unfortunately that is not enough; after running a small test - the clipboard was found to be sandboxed. In order to access the system clipboard, the script must be digitally signed. You can sign the applet privately for free to get it running on your machine, but this is probably not practical for you. To digitally sign your applet publicly, you have to go somewhere like Verisign and purchase a certificate for your applet. This currently costs $500 (US) for one year.

Another implication worth noting is that on the first time the JavaScript talks to the Java applet, it will take a little while to load the JVM (several seconds). Once the JVM is loaded it runs smoothly.

• Code
• Print

• Comment (0)
• Write

by Preview

Cancel reply

Write your comment

Comment's title

I assure 100% I am real human
I repeat I am not bot

• Sent (0)
• New