Java 7u4 webstart安全性exception：类与信任级别不匹配
我们开始注意到，使用Java 7（特别是更新4），我们的所有用户都开始使用我们的Webstart应用程序看到这一点：
[14:42:58,422] AWT-EventQueue-0(DEBUG) java.lang.SecurityException: class "CLASSNAME" does not match trust level of other classes in the same package [14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at java.security.AccessController.doPrivileged(Native Method) [14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader.findClass(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source) [14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)...More 其中CLASSNAME =几乎每个类都在应用程序执行中的几个jar子中的随机点，打破了几个行为。 如果我们的用户使用Java 6，他们没有问题！ 只是7（更新4）。 我们签署所有的jar子，主要的应用jar子和它的库jar子。 即启动我们的webstart应用程序的用户看到蓝色盾牌而不是黄色或红色。
这显然是一个问题，因为用户现在更频繁地升级到Java 7.我试图通过使用先前的安装（工作）或安装新的应用程序来强制我们的应用程序在用户计算机上使用Java 6 ….使用j2se version =“1.6”标记围绕资源，但这会导致它自己的问题，最好是进入它自己的线程（auto-jre-installation部分）。
Oracle是否通过Java 7u4破坏了Webstart安全性？ 如何解决此securityexception问题？
只是jarsigners hack签入的原始作者。我被另一个开发人员引导到这里，我最初与他分享了黑客攻击。
基于他对此的持续调查，您需要添加以下内容来调用hack
callNoArgMethod("getSigningData", jar); makeHardLink("signingDataRef", jar); callNoArgMethod("getManifest", jar); makeHardLink("manRef", jar, n);
清单调用不是此帖的解决方案的一部分。 在创建验收测试以重现问题时，会找到它们。
基于这个新信息，我们改变了我们的方法，我们现在使用reflection来调用所有“get”方法（如果没有填充，则需要调用get方法来初始填充软引用）
然后反思地发现CachedJarFile类中的所有软引用并为它们创建硬链接。
只要CachedJarFile保持不变并且黑客的基本前提保持正确，这就可以在未来certificate来自其他内部重命名/重构的解决方案。 （即：对软参考进行软参考。
我在1.7.07遇到了同样的问题：我的webstart应用程序在加载类时随机出现相同的错误消息。 我在这个页面oracle论坛上找到了一个有趣的解决方法。 最后一个答案描述了问题的解决方法（Java 6） – 对jar的签名的引用被保存为软引用，这些可能是垃圾收集，这会导致错误消息。 这可以用于Java 7以及一些额外的行
// Java 1.7 callNoArgMethod("getSigningData", jar); makeHardLink("signingDataRef", jar);
我想你可能正在经历这个bug 。
错误状态表示修复已在7u4中提供。 但这并不会与你所说的一致。 也许“修复”打破了….
与此同时，“squaat”对bug的评论提到了可能的解决方法。 例如，增加初始堆大小和/或使用预加载器强制某些JAR更早加载。
更新到JRE 8更新91之后我遇到了同样的问题。使用以前的版本1.6,1.7,1.8更新77我的应用程序运行正常。
Oracle是否重新引入了JRE 1.6 bug中存在的错误 ？
我发现的唯一工作是禁用Java控制面板中的混合代码控制。
我修好了它。 问题出在我的应用程序使用的库中。 jar子里的MANIFEST.MF是这样的：
Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 1.5.0_07-87 ("Apple Computer, Inc.") Built-By: wolf Name: common Specification-Title: swixml Specification-Vendor: swixml.org Specification-Version: 1.6 Implementation-Title: org.swixml Implementation-Vendor: swixml.org Implementation-Version: 1.6 beta 1 (#151)
“Name”属性用于特定于资源的条目，如http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest所述
签署此jar，“Name”条目被解释为资源，但没有资源可以签名。 启动应用程序时，javaws发现MANIFEST.MF中报告的资源与阻止应用程序的jar中的有效资源不匹配
我一直在使用JRE 7u5来解决相同的症状。 使用JRE 6u33，完全相同的应用程序Web启动没有问题。
在我的情况下，问题是由我的一个扩展jnlp文件引起的。 master jnlp文件指定了all-permissions安全性，而扩展jnlp没有声明任何特定的安全性要求（只是一个空的安全性标记）。
这导致扩展jar被加载到沙箱中。 显然，Java 7不接受混合具有不同安全要求的jar，即使它们都已签名。
通过确保所有扩展jnlp文件指定与主jnlp文件相同的安全性要求来解决此问题。