Breaking out of the Applet Sandbox
Most users would download and install software from unkown sources without even a blink of an eye. Sometimes these downloads contain trojans, worms, viruses and many other kinds of unfriendly creatures. Yet the same users are very worried about applets having access to their hard disk. Because of these unfounded fears applets are forced into a sandbox from which they cannot escape out of without the user's permission.
Before we go any further let's see what really happens when an applet tries to do something trivial like displaying an image stored on a remote webserver. While there's nothing wrong with the code itself, as you will see when you click on the demo link, the applet fails rather miserably. If you open the plug-in console window you will see a heap of error messages.
This article will attempt to provide two different solutions to overcome sandbox restrictions. The first approach which involves the use of signed applets can be used in almost any situation. The second approach is transparent to the user but cannot be used in certain situations.
Thanks to countless changes and bugs in different versions of the sdk, signed java applets have not found widespread use. Having created the signed applet you still need to convince the user to grant the additional permissions, so you may be better off with the alternative approach described in the second part of this article.
Applets are allowed to make connections to their own server. It's possible to make use of this in ertain situation such as retrieval of remote files over HTTP or FTP with the use of a script that acts as a proxy.
before you move on the the next page