Java applet清单 - 允许所有Caller-Allowable-Codebase

时间：2013-10-16 01:32:19

标签： java applet manifest signed-applet

从Java 7u45开始，如果网页尝试通过javascript与其进行交互，并且该页面未在清单的Caller-Allowable-Codebase属性中列出，则applet将显示警告消息（即使使用受信任的证书进行签名）。

发布有关此更改的说明：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

我只尝试过通配符（*），但我仍然收到警告。

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

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

Example of warning message

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

16 个答案:

答案 0 :(得分：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不起作用。

现在怎样？ 有没有人找到一种方法来允许具有“所有权限”的SIGNED小程序在两个JRE版本中都没有警告的情况下运行？

oracle到底出了什么问题？

答案 1 :(得分：26)

删除Trusted-Library属性似乎必须使Caller-Allowable-Codebase正常工作，不再需要警告。但是，如果签名的JAR文件没有使用Trusted-Library = true属性标记，则会破坏Java 7 Update 21 - 40，它会处理调用带有所有权限的已签名applet中的代码的JavaScript代码，因为会出现混合代码和警告对话框。

答案 2 :(得分：10)

根据oracle博客文章

，这将在未来版本中修复

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

他们认识到错误＆＃34;这两个属性应该协同工作以支持各种版本的客户端安装＆＃34;。但就目前而言，他们的解决方案是：＆＃34;目前的解决方案是支持使用Caller-Allowable-Codebase而不是旧的Trusted-Library调用。 ＆＃34;

答案 3 :(得分：6)

我有同样的问题。对我来说，解决方案是使用清单中的相同参数，就像Oracle在applet中的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

答案 4 :(得分：5)

来自oracle的

：

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

如果受信任的签名jar正在使用Caller-Allowable-Codebase清单属性以及Trusted-Library，那么将忽略Caller-Allowable-Codebase清单条目，结果是JavaScript - ＆gt; Java调用将显示本机LiveConnect警告。解决方法是删除Trusted-Library清单条目。

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

答案 5 :(得分：3)

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

在7u21和7u45及之前的版本中提供的主版本将具有新的Caller-Allowable-Codebase和没有Trusted-Library条目。制作的第二个版本将拥有Trusted-Library，仅供应给7u21,7u25和7u40。

这是一个用于创建带有修改过的清单的新jar的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启动我们的applet，因此我们使用它来决定标准和可信库applet：

        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';
        }

答案 6 :(得分：2)

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

答案 7 :(得分：2)

这组属性允许applet在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 - 我们爱你。

答案 8 :(得分：2)

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

答案 9 :(得分：2)

我现在发现我的一些用户仍然会收到“混合签名和未签名代码”警告（由于网页中的LiveConnect调用到applet），即使我已正确设置了Caller-Allowable-Codebase，获取它的那些与不能获得它的那些之间的区别在于它们是否在客户端主机中启用了applet .jar文件缓存。允许Java在客户端上保留临时文件的那些（即，允许缓存applet .jar文件）得到警告，并且那些关闭缓存的（因为applet缓存从未正常工作）不会得到警告。去图。

答案 10 :(得分：1)

不使用信任库并设置：

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

对我不起作用，我仍然看到警告。

更新：也尝试使用http：// ...但是也无效。

Update2 ：似乎更糟糕。我没有更新7u40（到7u45）但Java控制台（完全调试）显示“LiveConnect 1.7.45”文本。之后，我的Javascript-＆gt; Java调用被阻止。

更新3 ：我注意到我的警告显示了Application和Publisher = UNKNOWN。我有Altought：

Application-Name: MyApplet
Implementation-Vendor: MyCompany

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

答案 11 :(得分：1)

禁用此功能＆＃34;安全警告＆＃34;使用Java 8 Update 45 JRE的弹出窗口和其他相关弹出窗口。

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

注意：未使用通配符*和* .com。

禁用安全警告弹出窗口

答案 12 :(得分：0)

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

答案 13 :(得分：0)

编辑：事实证明，如果文件位于不同的目录中，我们的应用程序正在做一些不同的事情 - 特别是，它没有尝试访问applet签名的jar清单。因此，文件位于不同目录中的事实无关紧要。所以以下信息不准确。我决定在一个新问题中详细说明警告的真正原因：As of Java 7 update 45, one can no longer lookup manifest information without triggering a warning?

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

使用我的网络启动应用程序，一切都运行良好，花花公子，需要为7u21添加“信任库”属性。使用7u45，删除“Trusted-Library”属性并添加在其他答案中讨论的所有其他属性将不起作用 - 如果您运行的是没有Trusted-Library属性的7u21，我将收到相同的警告（说明应用程序包含有符号和无符号代码）。

我花了很多时间来解决这个问题，因为出于非常令人费解的原因，Oracle决定不打印任何关于“无符号”代码在其控制台中的含义的指示，即使在最大跟踪（第5级）运行时也是如此。但基本上，我们的应用程序需要访问配置文件，用户可以使用该配置文件来配置应用程序属性（例如，我们的应用程序的日志记录级别）。此配置文件是普通的旧文本文件。我们将配置文件存储在与应用程序运行位置相同的目录中：.. \ config \ app.properties。我们将此文件作为主jar的init例程的一部分进行访问。它在这里发出警告。

这里有解决方法吗？将app.properties移动到运行应用程序的同一目录中（并将jar中的引用更改为“app.properties”）。瞧，它工作 - 没有更多的警告（只要使用上述代码库属性）。到底是什么Oracle ???

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

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

有什么想法吗？而且由于Oracle打算无论如何都要修复Trusted-Library问题，所以提出一个（可能）宏伟的解决方案 - 解决这个问题甚至值得努力吗？哎呀....

答案 14 :(得分：0)

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

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

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

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

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

我因为没有最后一行而感到尴尬，它看起来像这样：

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

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

答案 15 :(得分：0)

如果您制作Manifest补丁文件，请记住最后生成空行，否则无法正常工作。 例如，您可以制作如下补丁：

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

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

然后将其添加到清单中：

jar uvfm jarName.jar permissions.txt
相关问题
最新问题