So we installed the Java 7u21 release that is supposed to tighten the security for applets. Unfortunately it tightened it so much that our applet does not run anymore. Not good.
The interesting thing is that it only stopped working while we operate it with JWS. If we launch it as a standard applet from a standard web page everything works fine.
In JWS mode we get security issues on at least reflection and java.lang.Thread.setDefaultUncaughtExceptionHandler
.
The certificates look ok.
The release notes from Oracle does not provide much input on anything related to JWS.
My question to the community is hence: does anyone have an idea or (even better) a solution to this?
Additional info related to the given suggestions/comments:
This applet is run by hundreds of third-party clients worldwide so changing the security policy is unfortunately not an option. The issue is reproducible for the clients. I can however confirm that changing the policy file resolves the issue.
When I run the applet from a Tomcat launched from Eclipse (thereby of course not having a signed applet) it brings up the warning notification in the browser as expected. Being the gullible person that I am I allow the applet to run since it was launched from my own dev environment. This still causes the security failure.
I have contemplated if this is a bug in Java but I want to see if there is anyone else seeing the same issue. I think we all know that the Oracle turnaround time for fixing bugs is not always the best...
Thanks for any input.
Thanks a lot Tony, your suggestion get me able to create applets in 7u21, propperly; i considered it as a forward step the fact that i am signing and waking up many applets yet over the browsers, these over 7u21. I culdn't to do it today earlier. But i get trapped since some hours, in the fact that i have not reached to wake my first third party applet from the legacy app i have (i.e. working fine in JVM 1.6 or the older).
The applets involved, i signed them, but i always get the error: SecurityException - "Bad applet class name". I have some applets, and html code calling them, the problem is that my first applet in chain (neither any other in the invoke chain) might not behave like the other signed applet are doing propperly (these applets are from java web site for training), this 3th party applet simple does not run and throw de exception above mentioned. My thrid part applet i dont know what it does internally. Sorry i might be asking for a particullar case that is no easy to solve without the source code, however, please trust to tell me any idea no matter wich it is.
best regards
You can either make sure that the applet is signed by a valid cert, and it is not a self-signed cert. Or if you just want to bypass the warning, you can add the domain address to Exception Site List. and also you may also try to add the website to the Trusted Zone in your IE if you are sure that the website is safe.
The browser, as a runtime, has become powerful enough to make Java Applets unnecessary. Modern webapps with some amount of JavaScript on the frontend replaced Java Applets. and if there is still a viable way to use my . jar file in a web app.
The applet element was deprecated in HTML 4.01 and rendered entirely obsolete by HTML5. Support for the Java browser plugin has been dropped by virtually all leading web browsers.
Here is the page that explains it.
Oracle Code on Mixed code
What you need to do is take all of your jars are get the new TrustedLibrary line in the manifest file. For me that meant a recompile of older code. You could probably just unjar the current jars and then rejar including the TrustedLibrary line.
You also MUST sign all of your code. Not just the applet. That means if you have 3 jars then all the code in all 3 jars must be signed also.
My colleague cracked it. Giving vodka to a Polish guy can sometimes produce the needed inspiration. :-)
Anyway, it seems like the security tag is now required in the jnlp information sent to the applet (what is being returned with content type set to application/x-java-jnlp-file).
By adding
<security> <all-permissions/> </security>
it works.
Hope this helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With