Манифест Java-апплета - разрешить все возможности Caller-Allowable-Codebase

Ответ 1

Удаление атрибута Trusted-Library, по-видимому, является обязательным для работы Caller-Allowable-Codebase, больше никаких предупреждений. Однако это перерывает Java 7 Update 21-40, который обрабатывает код JavaScript, который вызывает код в подписанном апплете со всеми разрешениями, так как смешанные коды и предупреждающие диалоги повышаются, если подписанные файлы JAR не помечены атрибутом Trusted-Library = true.

Ответ 2

Мои результаты совпадают:

Это предотвращает предупреждения с помощью Java 7u21 - 7u40:

Manifest-Version: 1.0
Trusted-Library: true

Это эксклюзивно предотвращает предупреждения с помощью Java 7u45:

Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

Смешивание обоих не будет работать в 7u45.

Теперь что? Кто-нибудь нашел способ разрешить запуск SIGNED-апплетов с "all-permissions" без предупреждений в обеих версиях JRE?

Что, черт возьми, неправильно с оракулом?

Ответ 3

Это будет исправлено в будущей версии, согласно сообщению в блоге oracle:

https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and

Они распознают ошибку "Оба эти атрибута должны работать вместе для поддержки различных версий клиентских установок". Но на данный момент их решение: "Текущая работа будет заключаться в том, чтобы использовать Caller-Allowable-Codebase по старому вызову Trusted-Library".

Ответ 4

У меня была такая же проблема. Решение для меня использовало те же параметры в манифесте, что и Oracle, используемый на странице donwload в апплете для проверки версии java http://www.java.com/en/download/installed.jsp Их апплет не выдает никаких предупреждений.

поэтому решение:

Манифест-версия: 1.0
Codebase: *
Разрешения: все разрешения
Доступная для библиотеки приложений-библиотека: *
Caller-Allowable-Codebase: *
Имя приложения: APPNAME

он работает на:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18

Ответ 5

из оракула:

Область: развертывание/плагин Сводка: Caller-Allowable-Codebase может игнорироваться при использовании с Trusted-Library.

Если доверенная подписанная банка использует атрибут манифеста Caller-Allowable-Codebase наряду с Trusted-Library, то запись манифеста Caller-Allowable-Codebase будет проигнорирована, и в результате JavaScript- > Java-вызов покажет встроенное предупреждение LiveConnect. Обходной путь заключается в удалении записи манифеста доверенной библиотеки.

http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html

Ответ 6

Единственное решение, которое я могу придумать для работы с версиями 7u45 и версий Trusted-Library (7u21, 7u25 и 7u40), - это создать два разных JAR с различными манифестми, а затем определить версию пользователя и загрузить правильный.

Основная версия поддерживалась версиями до 7u21 и 7u45, а вверху была бы новая запись Caller-Allowable-Codebase и без доверенной библиотеки. Вторая версия будет иметь Trusted-Library и будет обслуживаться только до 7u21, 7u25 и 7u40.

Вот макрос ant, чтобы создать новую банку с измененным манифестом:

<macrodef name="addtrustedlibrarytojar">
    <attribute name="jarpath" />
    <attribute name="newjarpath" />
    <sequential>
        <echo>Unzipping @{jarpath} to add Trusted-Library</echo>
        <mkdir dir="build/temp_trusted_library" />
        <unjar src="@{jarpath}" dest="build/temp_trusted_library" />

        <echo>Inserting Trusted-Library in manifest</echo>
        <replaceregexp match="^" replace="Trusted-Library: true${line.separator}" flags="s">
            <fileset dir="build/temp_trusted_library/META-INF" includes="MANIFEST.MF"/>
        </replaceregexp>

        <echo>Creating @{newjarpath}</echo>
        <zip file="@{newjarpath}" basedir="build/temp_trusted_library" />

        <echo>Deleting build/temp_trusted_library directory</echo>
        <delete dir="build/temp_trusted_library" />
    </sequential>
</macrodef>

Вызовите макрос как это для каждого JAR, которому необходимо внести изменения:

    <addtrustedlibrarytojar jarpath="dist/myapplet.jar" newjarpath="dist/myapplet_tl.jar" />

Не забудьте подписать новый JAR. Если это уже было подписано, это изменение приведет к аннулированию подписи.

Мы используем библиотеку PluginDetect для обнаружения версии Java. Просто извлеките PluginDetect_Java_Simple.js и getJavaInfo.jar. Этот код получит версию java:

<script type="text/javascript" src="js/PluginDetect_Java_Simple.js"></script>
<script type="text/javascript">
var javaVersionDetected = '0';
function javaDetectionDone(pd) {
    javaVersionDetected = pd.getVersion("Java");
    if (console) console.info('Detected java version: ' + javaVersionDetected);
}
PluginDetect.onDetectionDone("Java", javaDetectionDone, "js/getJavaInfo.jar", null);
</script>

Мы используем javascript для запуска наших апплетов, поэтому мы используем это для решения стандартных и доверенных библиотек:

        if (javaVersionDetected === '1,7,0,21' || javaVersionDetected === '1,7,0,25' || javaVersionDetected === '1,7,0,40') {
            if (console) console.debug('Using TL applet');
            attribs['archive'] = 'applets/myapplet_tl.jar';
        }
        else {
            if (console) console.debug('Using normal applet');
            attribs['archive'] = 'applets/myapplet.jar';
        }

Ответ 7

У меня была такая же проблема, поэтому я удаляю Trusted-Library = true из моего MANIFEST.MF, отлично работаю с атрибутом Caller-Allowable-Codebase.

Ответ 8

Этот набор атрибутов позволяет апплетам загружаться без предупреждений в Java 7u45:

Application-Name: ...
Main-Class: com...
Sealed: true
Codebase: *
Caller-Allowable-Codebase: *
Permissions: all-permissions

Мы тестировали следующие JVM:

• Java 6u20 (хорошо, ну дух!)
• Java 7u21 - должен включать Trusted-Library, чтобы избежать предупреждения
• Java 7u25 - должен включать Trusted-Library, чтобы избежать предупреждения
• Java 7u40 - должен включать Trusted-Library, чтобы избежать предупреждения
• Java 7u45

Итак, длинный и короткий - у нас есть дилемма; чтобы не было предупреждения на 7u21, 7u25 и 7u40, вы должны включить Trusted-Library: true и не иметь предупреждения на 7u45, вы должны опустить это свойство.

Спасибо Oracle за Кобаяси Мару - мы тебя любим.

Ответ 9

Для обновления 1.7.0_25 (и, вероятно, 21-40) установка параметров безопасности на "Средство" на панели управления Java → "Безопасность" удаляет запрос при использовании тегов манифеста для обновления 1.7.0_45.

Ответ 10

Теперь я обнаружил, что некоторые из моих пользователей по-прежнему получают предупреждение "смешанный подписанный и неподписанный код" (из-за звонков LiveConnect на веб-странице в апплет), хотя я правильно установил Caller-Allowable-Codebase, и разница между теми, которые его получают, и теми, которые этого не получают, является то, что на клиентском хосте активировано кэширование файлов .jar. Те, которые позволяют Java хранить временные файлы на клиенте (т.е. Разрешать кэширование файлов в виде апплетов.), Получают предупреждение, а те, которые переходят в кеширование (поскольку кэширование апплетов никогда не срабатывало), не получают предупреждения. Наведите указатель мыши.

Ответ 11

Без использования Trusted-Library и настройки:

Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

Не работает для меня, и я все еще вижу предупреждение.

Обновить: пробовал также с http://... но не работал.

Update2: Кажется еще хуже. Я не обновлял 7u40 (до 7u45), но Java-консоль (полная отладка) отображает текст LiveConnect 1.7.45. После этого мои Javascript- > вызовы Java блокируются.

Обновление 3. Я заметил, что мое предупреждение показывает Application and Publisher = UNKNOWN. У меня есть:

Application-Name: MyApplet
Implementation-Vendor: MyCompany

Я пытался использовать JDK7u45 вместо JDK7u5, который использовал.

Ответ 12

Чтобы отключить всплывающее окно "Предупреждение о безопасности" и другие связанные всплывающие окна с помощью Java JRE Update 45 JRE.

Trusted-Library: true
Caller-Allowable-Codebase: *.mycompany.com

Примечание: всплывающее окно с предупреждением безопасности не было отключено с помощью подстановочных знаков * и *.com.

Ответ 13

У нас тоже была эта проблема - мы строили с 1.4.2, по теории, что у клиентов может не быть обновленного плагина JRE. Несмотря на добавление новых атрибутов манифеста, мы все же получили всплывающие предупреждения в JRE 1.7_u45. Мы восстановили с 1.6, и предупреждения ушли.

Ответ 14

РЕДАКТИРОВАТЬ: Как оказалось, наше приложение делало что-то другое, если файл находился в другом каталоге - в частности, он не пытался получить доступ к манифестм подписанных апплетов. Таким образом, факт, что файл находился в другом каталоге, не имеет значения. Таким образом, приведенная ниже информация неточна. Я решил подробно объяснить настоящую причину предупреждения в новом вопросе: Что касается обновления Java 7 45, вы больше не можете искать информацию манифеста, не вызывая предупреждения?

К сожалению, обходной путь, данный Oracle и другими разработчиками для устранения проблемы с обновлением 45, НЕ работает, если вашему приложению требуется доступ к файлам в другом каталоге, кроме того, где выполняется приложение.

С моим веб-стартовым приложением все работало отлично и денди с атрибутом "Trusted-Library", который необходимо добавить для 7u21. С 7u45 удаление атрибута "Trusted-Library" и добавление во все дополнительные атрибуты, о которых говорили в других ответах, НЕ будет работать - я получу то же предупреждение, которое вы получите, если вы используете 7u21 без атрибута Trusted-Library (заявив, что приложение содержит как подписанный, так и неподписанный код).

Мне это потребовалось, чтобы понять это, потому что по очень необъяснимым причинам Oracle решила не печатать ЛЮБОЕ указание на то, что "неподписанный" код находится на своей консоли, даже при максимальной максимальной трассировке (уровень 5). Но в основном наше приложение нуждается в доступе к конфигурационному файлу, который может использоваться пользователем для настройки свойств приложения (например, уровня ведения журнала нашего приложения). Этот файл конфигурации представляет собой простой старый текстовый файл. И мы сохраняем файл конфигурации в директории, расположенной рядом с тем, где приложение работает:..\config\app.properties. Мы получаем этот файл как часть основной процедуры инициализации jar. Именно здесь происходит предупреждение.

Обходной путь здесь? Переместите app.properties в тот же каталог, в котором работает приложение (и измените ссылку в банке только на "app.properties" ). Voila, он работает - больше никаких предупреждений (пока используется вышеупомянутые атрибуты базы данных). Какого черта Oracle???

К сожалению, поскольку наше приложение позволяет настраивать конфигурационные файлы для каждого пользователя, нам не так просто просто поместить файл конфигурации в каталог запуска приложения - так как это НЕ настроено для каждого пользователя, мы могли бы позволить одному пользователю на одну машину одновременно использовать приложение.

Я просматривал документацию Java-манифеста, чтобы узнать, есть ли способ сделать файл конфигурационного файла "безопасным" таким, чтобы загрузка этого файла не вызывала предупреждения. Единственное, о чем я могу думать, - это либо использовать атрибут Class-Path, либо комбинацию атрибутов Extension (http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/extensions.html), однако эти все, похоже, разработаны вокруг цели банок, а не только обычных файлов...

Любые идеи? И поскольку Oracle все равно намерена исправить проблему с доверенной библиотекой, придумает (потенциально) грандиозное решение для решения этой проблемы, даже стоит того? Хмм....

Ответ 15

Я нашел странную вещь с файлом MANIFEST.MF в области последней проблемы безопасности Java с новым атрибутом "Caller-Allowable-Codebase". У меня были некоторые проблемы, почему этот новый атрибут не помог мне и начал расследование
( Внимание!: оно может быть связано только с моей локальной конфигурацией компьютера - потому что я никогда не видел таких проблем над stackoverlow).

Файл манифеста был обновлен в соответствии с новой функцией безопасности:

Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

и *.jar была создана, но без подписания.

Итак, я распаковал свой файл *.jar и посмотрел в папку META-INF в MANIFEST.MF, где должен быть сгенерирован источник manifest.mf.

И я был смущен отсутствием последней строки, это выглядело так:

Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *

Я несколько раз тестировал это поведение и выяснял, что последняя строка всегда заменялась пробелом. Итак, если это будет полезно для кого-то, просто добавьте в конец файла MANIFEST.MF какой-то неизмеримый атрибут, например Codebase: *, который будет разрезан во время сборки *.jar.

Ответ 16

если вы сделаете файл патча Manifest, помните, что в конце концов оставайтесь пустой строкой, иначе это не будет работать. Например, вы можете сделать патч, например:

Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

Но вам нужно добавить пустую строку (в примере 5 строк вместо четырех!)

И затем добавьте его в манифест:

jar uvfm jarName.jar permissions.txt