F**$#&% Java Policy Files

If you have ever had to modify a policy file, let me warn you of a wrinkle that you may run into IF your applet/java code needs to perform an operation that is authorized by the policy file BUT IS CALLED VIA JavaScript.

Guess what folks?  Java doesn't trust JavaScript any more (and hasn't intermittently over the past 5 years or so - sometimes trusting, sometimes not) so just because you gave your code a valid policy file grant, any code triggered via JavaScript will run as if being run outside the Java codebase (which in a way it is.)  This means that you have two options, one of which is not palatable, and the other can break backwards compatibility in your codebase.

(1)Grant permissions without using the codebase attribute (this is very very bad as your permission change will therefore grant the same permissions to ANY applet that the user runs into.)

(2)Surround the code that needs permissions privileges (and can be called via JavaScript) with a doPrivileged block.  The downside to this is that early versions of Java don't support this functionality; ergo you are (probably) forced to go the trusted/signed applet route (not good for many reasons.)

Luckily for me, I only need this functionality inside of a tool that is hosting my Java code, so I can put the non 1.1.8 jdk compliant code in my dynamically loaded adapter class that only ships with the offline tool.

Anyhow, I hope someone else trying to figure this out learns from this.

If your applet needs policy file permissions and your applet will be called from javascript, you must not only grant the applet the permissions in the appropriate fashion but also surround the code that can be triggered via JavaScript with a doPriveleged block.  This is because Java's runtime no longer executes javascript with the permissions levels of the applet.