Манифест апплета Java-разрешить все вызывающие-допустимые-кодовая база

мои выводы те же:

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

Manifest-Version: 1.0
Trusted-Library: true

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

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

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

теперь что? Кто-нибудь нашел способ разрешить подписанные апплеты со "всеми разрешениями" работать без предупреждений в обеих версиях JRE?

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

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

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

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

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

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

Манифест-Версия: 1.0
Кода: *
Разрешения: все разрешения
Application-Library-Allowable-Codebase:*
Caller-Allowable-Codebase:*
Приложение-имя: ИМЯ_ПРИЛОЖЕНИЯ

это работает:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-B18 и

от oracle:

Область: Развертывание / Плагин Синопсис: 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 и версиями доверенной библиотеки (7u21, 7u25 и 7u40), заключается в создании двух разных банок с разными манифестами, а затем обнаружении версии пользователя и загрузке правильной.

основная версия, обслуживаемая версиями до 7u21 и 7u45 и выше, будет иметь новую вызывающую допустимую кодовую базу и не будет записи доверенной библиотеки. Вторая выпущенная версия будет иметь доверенную библиотеку и будет обслуживаться только 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>

вызовите макрос вот так для каждой банки, которая нуждается в изменении:

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

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

мы используем PluginDetect библиотека для обнаружения версии Java. Просто извлеките PluginDetect_Java_Simple.js и getJavaInfo.сосуд. Этот код получит версия 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 из своего манифеста.MF, работа вызывающего абонента-допустимый атрибут кодовой базы штраф.

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

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

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

мы протестировали на следующих JVMs:

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

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

спасибо Oracle за Кобаяши Мару-мы вас любим.

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

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

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

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

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

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

обновление 3: Я заметил, что мое предупреждение показывает приложение и издатель = неизвестно. Altought i have:

Application-Name: MyApplet
Implementation-Vendor: MyCompany

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

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

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

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

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

EDIT: как оказалось, наше приложение делало что-то другое, если файл находился в другом каталоге-в частности, он не пытался получить доступ к манифестам jar с подписью апплета. Поэтому тот факт, что файл был в другом каталоге, не имел значения. Поэтому приведенная ниже информация не является точной. Я решил подробно описать реальную причину предупреждения в новом вопросе:начиная с обновления 45 Java 7, больше нельзя искать информацию манифеста без запуска a предупреждение?

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

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

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

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

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

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

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

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

файл манифеста был обновлен в соответствии с новой безопасностью особенность:

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

и *.кувшин был построен, но без подписание.

Так, тогда я распаковывается мой *.jar файл и посмотрел в папке META-INF в манифесте.МФ, где проявляется источником.mf должен быть сгенерирован.

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

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

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

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

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

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

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

jar uvfm jarName.jar permissions.txt