JDK-6784894 : Regression: applets loaded from local disk can not access co-located resources
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u11,6u12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-12-13
  • Updated: 2010-11-03
  • Resolved: 2009-01-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6
1.3.1_25Fixed 1.4.2_20Fixed 6u12 b03Fixed
Related Reports
Duplicate :  
JDK-6791926 - JApplet throw exception in JDK 1.6 update 11, but working in JDK 1.6 update 10
Description
The fix for 6716217 has introduced a regression where a developer's applet can no longer access its resources when loaded from the local disk. This issue is described on the forum thread http://forums.java.net/jive/thread.jspa?threadID=54799&tstart=0 .

A test case is attached. Navigate to the included HTML file. With 6u10 and earlier the applet will load. With 6u11 and later the applet will throw an AccessControlException that can be seen on the Java Console.

The directory setup is as follows:

   testcase/
            index.html
            jars/applet.jar
            images/image.jpg

The index.html references applet.jar in the applet tag. The codebase for the applet is set to be the "testcase" directory. The applet attempts to load the resource "images/image.jpg". With 6u11 and later this is throwing an AccessControlException because the applet is only receiving permissions to read recursively under the directory from which the jar was actually loaded rather than the codebase as in earlier releases.

This compatibility issue may impact an unknown number of developers.

One possible solution would involve granting permissions to read recursively under the document base of the applet.
Comments
EVALUATION Fix: 1. Check for "file" protocol URL specifically for document base, and only grant recursive codebase read permission to this. 2. If the document base file url is a unc url (contains hostname), do not grant recursive codebase read permission 3. If document base is null, do not grant recursive codebase read permission 4. to grant recursive codebase file read permission, the codesource url must either be a directory (class file case), or the codesource url must ends with .jar or .zip. 5. Include same changes for old plugin
18-12-2008
EVALUATION We are investigating how to fix the regression w/o undoing fix to 6716217
17-12-2008