Java applet清单 – 允许所有的Caller-Allowable-Codebase
从Java 7u45开始，如果网页尝试通过javascript与其交互，并且该页面未在清单的“调用者允许的代码库”属性中列出，小程序将显示一条警告消息（即使使用可信的证书进行签名）。
关于此更改的发行说明： 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#caller_allowable
我尝试了一个通配符（*），但我仍然得到警告。
除了列出所有可能运行的代码库之外，还有其他的解决办法吗？
这对我来说是一个问题，原因是这个小程序运行在许多不同的机器和networking上，但总是在不同位置的内部网上。 这个小应用程序还需要与javascript通信，因为它会与本地USB缩放进行通信并显示结果并与页面交互。
有问题的Applet： https ： //github.com/JaggedJax/CIO_Scale
删除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: *
混合两者将不能在7月45日工作。
怎么办？ 有没有人find一种方法来允许带有“所有权限”的SIGNED小程序在两个JRE版本中都不带警告地运行？
甲骨文到底怎么了？
根据甲骨文的博客文章，这将在未来的版本中得到修复：
https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
他们认识到错误“这两个属性应该一起工作来支持各种版本的客户端安装”。 但现在，他们的解决scheme是：“目前的解决方法是在旧的Trusted-Library调用上使用Caller-Allowable-Codebase。
我遇到过同样的问题。 对于我来说，解决scheme是在清单中使用相同的参数，在applet的donwload页面上使用OraclevalidationJava版本http://www.java.com/en/download/installed.jsp它们的applet不会popup任何警告。;
所以解决办法是：
Manifest-Version：1.0
Codebase：*
权限：全部权限
Application-Library-Allowable-Codebase：*
Caller-Allowable-Codebase：*
应用程序名称：APPNAME
它适用于：
1.7.0_17-B02
1.7.0_25-B17
1.7.0_45-B18
从oracle：
区域：部署/插件简介：与Trusted-Library一起使用时，可以忽略调用者允许的代码库。
如果一个受信任的，有签名的jar使用Caller-Allowable-Codebase清单属性和Trusted-Library，则调用者允许的代码清单条目将被忽略，结果，JavaScript-> Java调用将显示本地LiveConnect警告。 解决方法是除去可信库清单条目。
http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
我能想到的唯一解决scheme就是使用7u45和Trusted-Library版本（7u21,7u25和7u40），可以创build两个不同清单的JAR，然后检测用户的版本并加载正确的版本。
主要版本服务于7u21和7u45之前和之后的版本将具有新的主叫方允许代码库和无可信库入口。 所产生的第二个版本将有信任图书馆，将只服务于7月21日，7月25日和7日40。
这是一个antmacros来创build新的jar与修改后的清单：
<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调用macros：
<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'; }
我有同样的问题，所以我从我的MANIFEST.MF中删除Trusted-Library = true，工作的Caller-Allowable-Codebase属性罚款。
对于更新1.7.0_25（可能是21-40），在使用清单标签更新1.7.0_45时，在Java控制面板 – >安全选项卡中将安全设置设置为中。
这组属性允许applet在Java 7u45中没有警告的情况下加载：
Application-Name: ... Main-Class: com... Sealed: true Codebase: * Caller-Allowable-Codebase: * Permissions: all-permissions
我们已经在以下JVM上进行了testing：
- Java 6u20（好，好吧！）
-
Java 7u21– 必须包含Trusted-Library以避免警告 -
Java 7u25– 必须包含Trusted-Library以避免警告 -
Java 7u40– 必须包含Trusted-Library以避免警告 - Java 7u45
所以多空是我们两难的境地， 在7u21，7u25和7u40没有任何警告，你必须包含Trusted-Library：true，并且在7u45没有警告，你必须省略这个属性。
感谢甲骨文的小林丸 – 我们爱你。
我现在发现，即使我已经正确设置了Caller-Allowable-Codebase，我的一些用户仍然得到了这个“混合签名和未签名代码”警告（由于LiveConnect在网页中调用applet）在那些获得它的人和那些没有得到它的人之间是否在客户端主机中启用了applet .jar文件caching。 那些允许Java在客户端保留临时文件（即允许cachingapplet .jar文件）的语句会得到警告，而那些closurescaching的语句（因为appletcaching从来没有工作得很好）不会得到警告。 去搞清楚。
不使用Trusted-Library并设置：
Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: *
不适合我，我仍然看到警告。
更新 ：也尝试与http：// …但也没有工作。
更新2 ：似乎更糟。 我没有更新7u40（至7u45），但Java控制台（完整debugging）显示“LiveConnect 1.7.45”文本。 之后， 我的Javascript-> Java调用被阻止 。
更新3 ：我注意到我的警告显示应用程序和发布服务器= UNKNOWN。 Altought我有：
Application-Name: MyApplet Implementation-Vendor: MyCompany
我尝试使用JDK7u45而不是我正在使用的JDK7u5。
使用Java 8更新45 JRE禁用此“安全警告”popup窗口和其他相关popup窗口。
Trusted-Library: true Caller-Allowable-Codebase: *.mycompany.com
注意：安全警告popup窗口没有被禁用通配符*和* .com。
我们也有这个问题 – 我们用1.4.2来构build，理论上客户可能没有更新的JRE插件。 尽pipejoin了新的manifest属性，但是我们仍然在1.7_u45 JRE中获得了popup警告。 我们用1.6重build，警告消失了。
编辑：事实certificate，我们的应用程序正在做一些不同的东西，如果文件在不同的目录 – 具体来说，它不是试图访问小程序签名的jar清单。 所以文件是在不同的目录是不相关的。 所以下面的信息是不准确的。 我已经决定在一个新的问题中详细说明警告的真正原因： 从Java 7更新45开始，在不触发警告的情况下，不能再查找清单信息？
不幸的是，如果您的应用程序需要访问与运行应用程序的目录不同的目录中的文件，Oracle和其他用户在此解决更新问题的解决方法不起作用。
随着我的networking启动应用程序，一切工作正常，需要添加为7u21“可信库”属性的花花公子。 使用7u45，删除“Trusted-Library”属性并添加其他答案中提到的所有附加属性将不起作用 – 如果您运行的是没有Trusted-Library属性的7u21，我将得到相同的警告（说明应用程序包含签名和未签名的代码）。
我花了很长时间才弄明白这一点，因为由于非常莫名其妙的原因，Oracle决定不打印任何关于“无符号”代码在控制台中的指示，即使在最大跟踪（第5级）下运行。 但基本上，我们的应用程序需要访问configuration文件，用户可以使用它configuration应用程序属性（例如，我们的应用程序的日志logging级别）。 这个configuration文件是一个普通的旧文本文件。 而且我们将configuration文件存储在共同位于应用程序运行位置的目录中：.. \ config \ app.properties。 我们作为主jar的init例程的一部分访问这个文件。 就在这里发生警告。
解决方法在这里？ 将app.properties移动到应用程序所在的同一目录（并将jar中的引用更改为“app.properties”）。 瞧，它的工作 – 没有更多的警告（只要使用上述代码库属性）。 什么是甲骨文？
不幸的是，因为我们的应用程序允许在每个用户的基础上定制configuration文件，所以将configuration文件放在应用程序的启动目录中并不那么简单 – 因为这不是以每个用户为基础定制的，只能允许每台机器的一个用户同时使用该应用程序。
我一直在查看Java的清单文件，看看是否有一些方法，我可以使configuration文件目录“安全”，这样加载这个文件不会导致警告。 我唯一能想到的是能够使用Class-Path属性或Extension属性的组合（ http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/ extensions.html ），但是这些都是围绕jar子的目的而devise的，而不是普通的文件。
有任何想法吗？ 而且，既然甲骨文打算解决可信库问题，那么是否会提出一个（可能）macros大的解决scheme – 解决scheme呢？ 哎呀….
在最新的Java安全性问题的范围内，我发现MANIFEST.MF文件有一些奇怪的事情，并带有新的属性“ Caller-Allowable-Codebase ”。 我有一些问题，为什么这个新的属性对我没有帮助，并开始调查
（ 注意 ！它可能只与我的本地计算机configuration有关 – 因为我从来没有看到过stackoverlow的这种麻烦）。
清单文件已根据新的安全function进行了升级：
Manifest-Version: 1.0 Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: *
* .jar是build立，但没有签署。
于是，我解开了我的* .jar文件，并在MANIFEST.MF文件夹中查找META-INF文件，其中应该生成源manifest.mf。
最后一行的缺席令我感到尴尬，它看起来是这样的：
Manifest-Version: 1.0 Application-Library-Allowable-Codebase: *
我多次testing了这个行为，发现最后一行总是被交换到空白处。 所以，如果对某人有帮助，只需在MANIFEST.MF文件的末尾添加一些无意义的属性，如Codebase: * ，这将在* .jar构build期间切割。
如果你制作了一个Manifest补丁文件，记得最后要空出一行，否则就不能工作。 例如，你可以做一个补丁，如：
Permissions: all-permissions Codebase: * Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: *
但是你需要添加一个空行（在例子中是5行而不是4行）
然后将其添加到清单：
jar uvfm jarName.jar permissions.txt
