java.lang.SecurityException: информация о подписывающей стороне класса "XYZ" не совпадает с информацией о подписывающей стороне других классов в том же пакете - PullRequest
Новая
       11

java.lang.SecurityException: информация о подписывающей стороне класса "XYZ" не совпадает с информацией о подписывающей стороне других классов в том же пакете

4 голосов
/ 27 августа 2009

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

1 Ответ

5 голосов
/ 27 августа 2009

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

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

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

...