Манифест Java-апплета - Разрешить все Caller-Allowable-Codebase
Начиная с Java 7u45, апплет будет отображать предупреждающее сообщение (даже если оно подписано доверенным сертификатом), если веб-страница пытается взаимодействовать с ним через javascript и эта страница не указана в атрибуте манифеста Caller-Allowable-Codebase.
Примечания к выпуску об этом изменении: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
Сообщение в блоге Oracle об этой ошибке: https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
Описание атрибута: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html
Я пробовал просто подстановочный знак (*), но я все еще получаю предупреждение.
Есть ли способ обойти это, кроме перечисления всех кодовых баз, на которых он может работать?
Причина, по которой для меня это проблема, заключается в том, что этот апплет работает на многих разных машинах и в сетях, но всегда в интрасетях в разных местах. Этот апплет также должен взаимодействовать с JavaScript, потому что он общается с локальными масштабами USB и отображает результаты и взаимодействует со страницей.
Апплет в вопросе: https://github.com/JaggedJax/CIO_Scale
16 ответов
Удаление атрибута Trusted-Library, по-видимому, является обязательным условием для работы Caller-Allowable-Codebase, без предупреждений. Однако это нарушает Java 7 Update 21 - 40, в котором код JavaScript, который вызывает код в подписанном апплете, работающем со всеми разрешениями, как смешанный код и диалоговые окна с предупреждениями появляются, если подписанные файлы JAR не помечены атрибутом Trusted-Library=true.
Мои выводы совпадают:
Это предотвращает предупреждения с 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 с "полными правами" работать без предупреждений в обеих JRE-версиях?
Что, черт возьми, не так с оракулом?
Это будет исправлено в следующем выпуске, согласно сообщению в блоге оракула:
https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
Они распознают ошибку "Оба эти атрибута должны работать вместе для поддержки различных версий установок клиента". Но на данный момент их решение таково: "Текущий обходной путь заключается в предпочтении использования Caller-Allowable-Codebase по сравнению со старым вызовом Trusted-Library".
Я была такая же проблема. Решением для меня было использование тех же параметров в манифесте, что и Oracle, который использовался на странице donwload в апплете для проверки версии java http://www.java.com/en/download/installed.jsp Их апплет не отображает никаких предупреждений.
Итак, решение:
Манифест-Версия: 1.0
Кодовая база: *
Разрешения: все-разрешения
Application-Library-Allowable-Codebase: *
Абонентская кодовая база: *
Имя приложения: APPNAME
это работает на:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18
Из оракула:
Область: Развертывание / Плагин. Краткое описание: Caller-Allowable-Codebase может игнорироваться при использовании с Trusted-Library.
Если доверенный подписанный jar-файл использует атрибут манифеста Caller-Allowable-Codebase вместе с Trusted-Library, тогда запись манифеста Caller-Allowable-Codebase будет игнорироваться, и в результате вызов JavaScript -> Java покажет собственный LiveConnect предупреждение. Временное решение: удалить запись манифеста доверенной библиотеки.
http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
Единственное решение, которое я могу придумать, которое работает с 7u45 и версиями Trusted-Library (7u21, 7u25 и 7u40), - это создать два разных JAR-файла с разными манифестами, а затем определить версию пользователя и загрузить нужную версию.
Основная версия, обслуживаемая до версий 7u21 и 7u45 и выше, будет иметь новую базу кодов-допустимых номеров вызовов и не будет иметь записи в Trusted-Library. Вторая произведенная версия будет иметь Trusted-Library и будет обслуживаться только до 7u21, 7u25 и 7u40.
Вот макрос муравья для создания нового фляги с измененным манифестом:
<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';
}
У меня была такая же проблема, поэтому я удаляю Trusted-Library=true из моего файла MANIFEST.MF, работающий атрибут Caller-Allowable-Codebase отлично.
Теперь я обнаружил, что некоторые из моих пользователей все еще получают это предупреждение "смешанный подписанный и неподписанный код" (из-за вызовов LiveConnect на веб-странице апплета), хотя я правильно установил Caller-Allowable-Codebase и разницу между теми, кто его получает, и теми, которые его не получают, заключается в том, включено ли на клиентском хосте кэширование файла апплета.jar. Те, которые позволяют Java сохранять временные файлы на клиенте (т. Е. Разрешают кэширование файлов.jar апплета), получают предупреждение, а те, которые отключили кэширование (поскольку кэширование апплета никогда не работало совершенно правильно), не получают предупреждение. Пойди разберись.
Этот набор атрибутов позволяет апплету загружаться без предупреждений в Java 7u45:
Application-Name: ...
Main-Class: com...
Sealed: true
Codebase: *
Caller-Allowable-Codebase: *
Permissions: all-permissions
Мы протестировали на следующих JVM:
- Ява 6u20 (ок, ну да!)
Java 7u21- должна включать Trusted-Library, чтобы избежать предупрежденияJava 7u25- должна включать Trusted-Library, чтобы избежать предупрежденияJava 7u40- должна включать Trusted-Library, чтобы избежать предупреждения- Java 7u45
Таким образом, у нас есть дилемма; чтобы не иметь предупреждений о 7u21, 7u25 и 7u40, необходимо включить Trusted-Library: true, а чтобы не иметь предупреждений о 7u45, вы должны опустить это свойство.
Спасибо Оракул за Кобаяси Мару - мы любим тебя.
Для обновления 1.7.0_25 (и, вероятно, 21-40) установка параметров безопасности на Средний на панели управления Java -> вкладка Безопасность удаляет запрос при использовании тегов манифеста для обновления 1.7.0_45.
Чтобы отключить это всплывающее окно "Предупреждение о безопасности" и другие связанные всплывающие окна с помощью Java 8 Update 45 JRE.
Trusted-Library: true
Caller-Allowable-Codebase: *.mycompany.com
Примечание: всплывающее окно с предупреждением безопасности не было отключено с использованием подстановочных знаков * и *.com.
Без использования Trusted-Library и настройки:
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
У меня не работает, и я все еще вижу предупреждение.
Обновление: пробовал также с http://... но тоже не работал.
Обновление 2: кажется, еще хуже. Я не обновил 7u40 (до 7u45), но консоль Java (полная отладка) показывает текст "LiveConnect 1.7.45". После этого мои вызовы Javascript->Java блокируются.
Обновление 3: я заметил, что мое предупреждение показывает Application and Publisher = UNKNOWN. Хотя у меня есть:
Application-Name: MyApplet
Implementation-Vendor: MyCompany
Я попытался использовать JDK7u45 вместо JDK7u5, который я использовал.
У нас тоже была эта проблема - мы строили с 1.4.2, основываясь на теории, что клиенты могут не иметь обновленного плагина JRE. Несмотря на добавление новых атрибутов манифеста, мы все равно получили всплывающие предупреждения в 1.7_u45 JRE. Мы восстановили с 1.6, и предупреждения ушли.
РЕДАКТИРОВАТЬ: Как выяснилось, наше приложение делало что-то другое, если файл находился в другом каталоге - в частности, он не пытался получить доступ к подписанным манифестам апплета jar. Поэтому тот факт, что файл находился в другом каталоге, не имеет значения. Поэтому приведенная ниже информация не является точной. Я решил уточнить реальную причину предупреждения в новом вопросе: Начиная с Java 7, обновление 45, нельзя больше искать информацию о манифесте, не вызывая предупреждение?
К сожалению, решение, данное Oracle и другими здесь для решения проблемы обновления 45, НЕ работает, если вашему приложению необходим доступ к файлам в другом каталоге, чем то, из которого приложение запускается.
С моим приложением для запуска через Интернет все работало нормально и прекрасно с атрибутом Trusted-Library, который нужно было добавить для 7u21. В 7u45 удаление атрибута "Trusted-Library" и добавление всех дополнительных атрибутов, о которых говорилось в других ответах, НЕ будут работать - я получу то же предупреждение, что и вы, если бы вы использовали 7u21 без атрибута Trusted-Library (заявив, что приложение содержит как подписанный, так и неподписанный код).
Мне НАВСЕГДА потребовалось выяснить это, потому что по очень необъяснимым причинам Oracle решила не распечатывать ЛЮБОЕ указание того, что представляет собой "беззнаковый" код в его консоли, даже при работе с максимальной трассировкой (уровень 5). Но в основном нашему приложению необходим доступ к файлу конфигурации, который может использоваться пользователем для настройки свойств приложения (например, уровня ведения журнала нашего приложения). Этот файл конфигурации представляет собой простой старый текстовый файл. И мы сохраняем файл конфигурации в каталоге, расположенном в том месте, откуда запускается приложение: ..\config\app.properties. Мы получаем доступ к этому файлу как часть процедуры инициализации основного фляги. Именно здесь происходит предупреждение.
Обходной путь здесь? Переместите app.properties в тот же каталог, из которого выполняется приложение (и измените ссылку в jar-файле на "app.properties"). Вуаля, это работает - больше никаких предупреждений (при условии использования вышеупомянутых атрибутов кодовой базы). Какого черта оракул???
К сожалению, поскольку наше приложение позволяет настраивать конфигурационные файлы для каждого пользователя, нам не так просто поместить файл конфигурации в каталог запуска приложения - так как это НЕ настраивается для каждого пользователя, мы бы только один пользователь может использовать приложение на одном компьютере одновременно.
Я просматривал документацию Java-манифеста, чтобы узнать, есть ли какой-нибудь способ сделать каталог файлов конфигурации "безопасным", чтобы загрузка этого файла не вызывала предупреждение. Единственное, о чем я могу думать, это возможность использовать атрибут Class-Path или комбинацию атрибутов Extension ( http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/extensions.html), однако, все они, похоже, предназначены для работы с банками, а не просто с обычными файлами...
Есть идеи? И поскольку Oracle намерена решить проблему Trusted-Library в любом случае, придумываете ли (потенциально) грандиозное обходное решение для решения этой проблемы, даже стоит ли усилий? Хмм....
Если вы создаете файл патча Manifest, не забудьте в конце оставить пустую строку, иначе это не сработает. Например, вы можете сделать патч как:
Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Но вам нужно добавить пустую строку (в примере 5 строк вместо четырех!)
А затем добавьте его в манифест:
jar uvfm jarName.jar permissions.txt
Я обнаружил странную вещь с файлом MANIFEST.MF в рамках последней проблемы безопасности Java с новым атрибутом "Caller-Allowable-Codebase". У меня были некоторые проблемы, почему этот новый атрибут мне не помог и начал расследование
(Внимание! Это может быть связано только с конфигурацией моего локального компьютера - потому что я никогда не сталкивался с такими проблемами по сравнению со стеком ниже).
Файл манифеста был обновлен в соответствии с новой функцией безопасности:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
и *.jar был собран, но без подписи.
Итак, я распаковал свой файл *.jar и посмотрел в папке META-INF в MANIFEST.MF, где должен быть сгенерирован исходный манифест.mf.
И меня смутило отсутствие последней строки, это выглядело так:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Я протестировал это поведение несколько раз и обнаружил, что последняя строка всегда заменяется на пробел. Так что, если это будет полезно для кого-то, просто добавьте в конец файла MANIFEST.MF какой-нибудь лишний атрибут, например Codebase: *, который будет вырезан во время сборки *.jar.