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 пользователей, у которых есть этот апплет, но затронуты лишь немногие, и даже у них проблема возникает лишь изредка.


applet java securityexception
person paul    schedule 27.08.2009    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Это означает, что внутри той же JVM есть другие классы, загруженные из других jar-файлов, которые были подписаны по-разному (или, возможно, не подписаны), также в пакете по умолчанию.

Если я правильно интерпретирую ваш вопрос, у самого вашего апплета есть только одна банка, поэтому это должна быть банка откуда-то еще; которые есть только у некоторых пользователей. Сначала я подумал, что это может быть jar апплета, работающего на другой вкладке (который может использовать тот же экземпляр jvm). Но другие апплеты должны использовать отдельный загрузчик классов, поэтому они не должны конфликтовать. Скорее всего, у них есть jar в загрузочном пути к классам их jvm, у которого также есть класс в корневом пакете.

В любом случае решение/обходной путь заключается в том, чтобы просто использовать не пакет по умолчанию, а ваш собственный пакет. Таким образом, вы избежите столкновения с другой банкой.

person Wouter Coekaerts    schedule 27.08.2009