java.lang.SecurityException:类“XYZ”的签名者信息与同一包中其他类的签名者信息不匹配
我有一个在浏览器中运行并从 Javascript 调用的小程序。有 2 个类:PortalLauncher 和 ParamSplitter,它们位于默认包中。 Javascript 调用PortalLauncher 中的方法,而该方法又调用ParamSplitter 中的函数。该小程序位于一个签名罐子中。
这在大多数情况下都有效。然而,少数用户时不时会遇到问题。在一天中的某个时间(即不是在第一次访问时)会引发以下异常:
java.lang.SecurityException: class "ParamSplitter"'s signer information does not
match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at PortalLauncher.openFile(PortalLauncher.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
java.lang.Exception: java.lang.SecurityException: class "ParamSplitter"'s signer
information does not match signer information of other classes in the same package
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
任何人都可以阐明此异常的含义以及可能导致该异常的原因吗?大约有 800 名用户拥有此小程序,但只有少数用户受到影响,即使这些用户也只是偶尔出现问题。
I have an applet which runs in a browser and is called from Javascript. There are 2 classes: PortalLauncher and ParamSplitter and these are in the default package. Javascript calls a method in PortalLauncher which in turn calls a function in ParamSplitter. The applet is in a signed jar.
This works most of the time. However, a few users have problems from time to time. At some time in the day (i.e. not on first access) the following exception is thrown:
java.lang.SecurityException: class "ParamSplitter"'s signer information does not
match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at PortalLauncher.openFile(PortalLauncher.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
java.lang.Exception: java.lang.SecurityException: class "ParamSplitter"'s signer
information does not match signer information of other classes in the same package
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
Can anyone throw any light on what this exception means and what might be causing it? There are about 800 users who have this applet but only a handfull are affected and even those have the problem only occaisionally.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这意味着在同一个 JVM 中,还有从其他 jar 加载的其他类,这些类的签名不同(或者可能没有签名),也在默认包中。
如果我正确地解释你的问题,你的小程序本身只有一个罐子,所以它一定是来自其他地方的罐子;只有部分用户拥有。
我的第一个想法可能是在另一个选项卡中运行的小程序的 jar(可以使用相同的 jvm 实例)。但其他小程序应该使用单独的类加载器,因此它们不应该像那样发生冲突。
更有可能的是,他们的 jvm 的引导类路径中有一个 jar,该 jar 在根包中也有一个类。
无论哪种方式,解决方案/解决方法就是不使用默认包,而是使用您自己的包。这样你就可以避免与另一个罐子碰撞。
It means that inside the same JVM, there are other classes loaded from other jars that have been signed differently (or not signed maybe), also in the default package.
If I interpret your question correctly your applet itself only has one jar, so it must be a jar coming from somewhere else; that only some users have.
My first thought it's maybe the jar of an applet running in another tab (that can be using the same jvm instance). But other applets should be using a separate classloader, so they shouldn't collide like that.
More likely, they have a jar in the boot classpath of their jvm that also has a class in the root package.
Either way, the solution/workaround is simply not to use the default package, but your own package. That way you avoid colliding with the other jar.