Description of problem:
I ave a java applet located in www.pippo.it/java/versione.jar
The applet is called from some html pages located in some folders (es. www.pippo.it/ita/dir/page.html).
It seems illogical to copy the same applet in all folders of the html pages that recall it.
This is the html code:
La versione di java installata sul tuo computer è la seguente:
<object type="application/x-java-applet" width="200" height="20" name="Versione java">
<param name="code" value="Versione.class"/>
<param name="archive" value="../../java/versione.jar"/>
<param name="permissions" value="sandbox"/>
nessuna. Devi <a href="http://www.java.com/it" target="java">installare</a> o abilitare java!
But there is always a security warning appears all times:
The application Versione java from
http://www.pippo.it/ita/dir/page.html uses resources from the
following remote locations:
Be very careful when application is loading from different space then
you expect. Are you sure you want to run this application?
For more information see:
JAR File Manifest Attributes
Preventing the Repurpsing of an Application
Note that the line "Codebase: www.pippo.it" in MANIFEST.MF is ignored.
Note also that "../../java/versione.jar" is not outside of the domain.
I do not understand the problem for security if the java applet and html page that calls it are in two different folders of the same domain!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Security warning if html page and jar are in different folders
Security warning only if html and jar are in different domains
Unluckily, the directories are part of the check intentionally.
The correct way to fix it is on your side:
Sign it, and put into manifest the locations from which your applet is expected to run (or if you do not care then just asterix and kill this safety belt) - http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library . Generally, fill all the attributes in. Sorry. This security enhancement is not from my head but after some judging.. it is useful.
The less correct workaround is for your clients - to disable manifest checks - in deployment.properties add