65

从 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#caller_allowable

我只尝试了通配符 (*)，但仍然收到警告。

除了列出它可能运行的所有代码库之外，还有其他方法吗？

这对我来说是个问题的原因是这个小程序在许多不同的机器和网络上运行，但总是在不同位置的 Intranet 上运行。这个小程序还需要与 javascript 通信，因为它与本地 USB 秤通信并显示结果并与页面交互。

警告信息示例

有问题的小程序：https ://github.com/JaggedJax/CIO_Scale

4

16 回答 16

35

我的发现是一样的：

这可以防止 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 版本中运行而不会发出警告？

甲骨文到底有什么问题？

于 2013-10-16T09:56:21.827 回答
26

要使 Caller-Allowable-Codebase 正常工作，似乎必须删除 Trusted-Library 属性，不再发出警告。但是，这会破坏 Java 7 更新 21 - 40，它将调用以所有权限运行的签名小程序中的代码的 JavaScript 代码视为混合代码，如果签名的 JAR 文件未使用 Trusted-Library=true 属性标记，则会引发警告对话框。

于 2013-10-16T08:53:35.390 回答
10

根据 oracle 博客文章，这将在未来的版本中修复：

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

他们认识到错误“这两个属性应该一起工作以支持各种版本的客户端安装”。但就目前而言，他们的解决方案是：“目前的解决方法是倾向于使用 Caller-Allowable-Codebase 而非旧的 Trusted-Library 调用。”

于 2013-10-21T09:11:43.650 回答
6

我遇到过同样的问题。对我来说，解决方案是在清单中使用与 Oracle 在 applet 的 donwload 页面上使用的参数相同的参数来验证 java 版本http://www.java.com/en/download/installed.jsp 他们的 applet 不会弹出任何警告。

所以解决方案是：


清单版本：1.0代码库
：*
权限：所有权限
应用程序库允许代码库：*
调用者允许代码库：*
应用程序名称：APPNAME

它适用于：
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45 -b18

于 2013-10-16T13:27:18.763 回答
5

来自甲骨文：

区域：部署/插件概要：与 Trusted-Library 一起使用时，Caller-Allowable-Codebase 可能会被忽略。

如果受信任的签名 jar 使用 Caller-Allowable-Codebase 清单属性和 Trusted-Library，则 Caller-Allowable-Codebase 清单条目将被忽略，因此，JavaScript -> Java 调用将显示本机 LiveConnect警告。解决方法是删除 Trusted-Library 清单条目。

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

于 2013-10-16T13:23:45.120 回答
3

我能想到的唯一适用于 7u45 和 Trusted-Library 版本（7u21、7u25 和 7u40）的解决方案是创建两个具有不同清单的不同 JAR，然后检测用户的版本并加载正确的版本。

提供给 7u21 和 7u45 及更高版本的主版本将具有新的 Caller-Allowable-Codebase 并且没有 Trusted-Library 条目。生成的第二个版本将具有 Trusted-Library，并且仅适用于 7u21、7u25 和 7u40。

这是一个 ant 宏，用于使用修改后的清单创建新 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 调用这样的宏：

    <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';
        }
于 2013-10-18T14:00:57.967 回答
2

对于更新 1.7.0_25（可能是 21-40），在 Java 控制面板 -> 安全选项卡中将安全设置设置为中会删除使用更新 1.7.0_45 的清单标记时的提示。

于 2013-10-17T11:58:17.373 回答
2

我有同样的问题，所以我从我的 MANIFEST.MF 中删除了 Trusted-Library=true，Caller-Allowable-Codebase 属性正常工作。

于 2013-10-16T07:10:18.923 回答
2

这组属性允许在 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 提供 Kobayashi Maru——我们爱你。

于 2013-10-16T23:24:05.683 回答
2

我现在发现，即使我正确设置了 Caller-Allowable-Codebase，我的一些用户仍然会收到此“混合签名和未签名代码”警告（由于 Web 页面中的 LiveConnect 调用到小程序），并且差异获得它的人和没有获得它的人之间的区别在于他们是否在客户端主机中启用了applet .jar 文件缓存。那些允许Java 将临时文件保存在客户端（即，允许缓存applet .jar 文件）的那些会收到警告，而那些关闭缓存（因为applet 缓存从未完全正常工作）的那些不会收到警告。去搞清楚。

于 2013-11-20T19:33:19.380 回答
1

不使用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。Altought我有：

Application-Name: MyApplet
Implementation-Vendor: MyCompany

我尝试使用 JDK7u45 而不是我正在使用的 JDK7u5。

于 2013-10-16T08:15:37.793 回答
1

使用 Java 8 Update 45 JRE 禁用此“安全警告”弹出窗口和其他相关弹出窗口。

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

注意：安全警告弹出窗口没有被通配符 * 和 *.com 禁用。

于 2015-05-27T14:34:52.030 回答
0

我在新属性“ Caller-Allowable-Codebase ”的最后一个 Java 安全问题范围内发现 MANIFEST.MF 文件有些奇怪。我遇到了一些问题，为什么这个新属性对我没有帮助并开始调查
（注意！：它可能仅与我的本地计算机配置有关 - 因为我从未见过 stackoverlow 出现这样的麻烦）。

清单文件已根据新的安全功能进行了升级：

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

并且 *.jar 已构建，但没有签名。

所以，然后我解压缩了我的 *.jar 文件并查看了 MANIFEST.MF 中的 META-INF 文件夹，其中应该生成 source manifest.mf。

最后一行的缺失让我感到尴尬，它看起来是这样的：

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

我多次测试了这种行为，发现最后一行总是被交换到空白处。因此，如果它对某人有帮助，只需在 MANIFEST.MF 文件的末尾附加一些无意义的属性，例如Codebase: *，它将在 *.jar 构建期间被删除。

于 2013-12-13T15:41:59.427 回答
0

如果您制作 Manifest 补丁文件，请记住最后留一个空行，否则它将无法工作。例如，您可以制作如下补丁：

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

但是您需要添加一个空行（在示例中是 5 行而不是 4 行！）

然后将其添加到清单中：

jar uvfm jarName.jar permissions.txt
于 2014-01-06T15:19:08.903 回答
0

我们也遇到了这个问题——我们使用 1.4.2 构建，理论上客户端可能没有更新的 JRE 插件。尽管添加了新的清单属性，我们仍然在 1.7_u45 JRE 中收到弹出警告。我们用 1.6 进行了重建，警告消失了。

于 2013-10-16T06:09:35.697 回答
0

编辑：事实证明，如果文件位于不同的目录中，我们的应用程序正在做一些不同的事情——特别是，它没有尝试访问小程序签名的 jar 清单。因此，文件位于不同目录中的事实是无关紧要的。所以下面的信息是不准确的。我决定在一个新问题中详细说明警告的真正原因：从 Java 7 更新 45 开始，是否无法在不触发警告的情况下查找清单信息？

不幸的是，如果您的应用程序需要访问与运行应用程序不同的目录中的文件，Oracle 和其他人在此处为解决更新 45 问题提供的解决方法不起作用。

使用我的 web start 应用程序，一切正常，并且需要为 7u21 添加“Trusted-Library”属性。使用 7u45，删除“Trusted-Library”属性并添加其他答案中讨论的所有其他属性将不起作用 - 如果您在没有 Trusted-Library 属性的情况下运行 7u21，我将收到相同的警告（说明应用程序包含签名和未签名的代码）。

我花了永远的时间才弄清楚这一点，因为出于非常莫名其妙的原因，Oracle 决定不打印任何有关“未签名”代码在其控制台中的指示，即使在最大跟踪（级别 5）下运行也是如此。但基本上，我们的应用程序需要访问一个配置文件，用户可以使用该配置文件来配置应用程序属性（例如，我们应用程序的日志级别）。此配置文件是一个普通的旧文本文件。我们将配置文件存储在与应用程序运行位置相同的目录中：..\config\app.properties。我们将这个文件作为主 jar 的 init 例程的一部分来访问。正是在这里出现警告。

这里的解决方法？将 app.properties 移动到运行应用程序的同一目录中（并将 jar 中的引用更改为“app.properties”）。瞧，它起作用了——不再有警告（只要使用上述代码库属性）。什么甲骨文？？？

不幸的是，因为我们的应用程序允许基于每个用户自定义配置文件，所以我们将配置文件放在应用程序的启动目录中并不那么简单——因为这不是基于每个用户自定义的，我们会每台机器只能允许一个用户同时使用该应用程序。

我一直在查看 Java 的清单文档，看看是否有某种方法可以使配置文件目录“安全”，以便加载此文件不会导致警告。我唯一能想到的就是能够使用 Class-Path 属性或 Extension 属性的组合（http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/ extensions.html），但是这些似乎都是围绕 jars 的目的设计的，而不仅仅是常规文件......

有任何想法吗？并且由于 Oracle 无论如何都打算修复 Trusted-Library 问题，是否会提出一个（可能）宏伟的变通解决方案来解决这个问题，甚至值得付出努力吗？咕噜……

于 2013-11-16T18:49:30.990 回答