-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
7u40
-
windows_7
FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
The getCodeBase() and getDocumentBase() Applet methods now return null if the applet is running on a local file system, even if the applet is signed with all-permissions.
These changes break our FindinSite-CD applet which is in use by many people on CDs etc, ie our applet is rendered useless for people with existing CDs.
http://www.phdcc.com/fiscd/
FindinSite-CD has worked since Java 1.0.2 using these basic methods to find its own directory so as to load data files in the same directory or lower, ie within the original sandbox.
Making these methods return null does not stop our all-permissions applet from accessing anywhere on the user's computer - instead it just makes it tricky to find where to load from.
The recommended workarounds are to include info in the JAR and use other methods to find a location. Our signed applet is used by CD developers to put on CD with the needed data files that they generate with our wizard. It is not practical/possible from them to put the data into our signed JAR.
I can adapt our recommended code for users to include JavaScript to pass the current URL to the applet (or other options), but it is silly to have to do this step - and it doesn't help the people who have existing CDs using our tool.
The basic sandbox should only allow access to the code or document base or lower - returning to this expected behaviour is the preferable solution.
A less satisfactory, but workable for us solution, is to allow all-permissions applets to get good results from getCodeBase() and getDocumentBase().
An alternative solution is to return a fabricated URL that doesn't give real path information, but none-the-less provides access to local files.
REGRESSION. Last worked in version 7u21
REPRODUCIBILITY :
This bug can be reproduced always.
A DESCRIPTION OF THE PROBLEM :
The getCodeBase() and getDocumentBase() Applet methods now return null if the applet is running on a local file system, even if the applet is signed with all-permissions.
These changes break our FindinSite-CD applet which is in use by many people on CDs etc, ie our applet is rendered useless for people with existing CDs.
http://www.phdcc.com/fiscd/
FindinSite-CD has worked since Java 1.0.2 using these basic methods to find its own directory so as to load data files in the same directory or lower, ie within the original sandbox.
Making these methods return null does not stop our all-permissions applet from accessing anywhere on the user's computer - instead it just makes it tricky to find where to load from.
The recommended workarounds are to include info in the JAR and use other methods to find a location. Our signed applet is used by CD developers to put on CD with the needed data files that they generate with our wizard. It is not practical/possible from them to put the data into our signed JAR.
I can adapt our recommended code for users to include JavaScript to pass the current URL to the applet (or other options), but it is silly to have to do this step - and it doesn't help the people who have existing CDs using our tool.
The basic sandbox should only allow access to the code or document base or lower - returning to this expected behaviour is the preferable solution.
A less satisfactory, but workable for us solution, is to allow all-permissions applets to get good results from getCodeBase() and getDocumentBase().
An alternative solution is to return a fabricated URL that doesn't give real path information, but none-the-less provides access to local files.
REGRESSION. Last worked in version 7u21
REPRODUCIBILITY :
This bug can be reproduced always.
- duplicates
-
-
- Closed
-