【问题标题】:Java applet manifest - Allow all Caller-Allowable-CodebaseJava 小程序清单 - 允许所有 Caller-Allowable-Codebase
【发布时间】:2013-10-24 00:02:00
【问题描述】:

从 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

【问题讨论】:

  • 我也有同样的问题,我觉得签名的小程序需要这个很可笑,我还没有想出解决方案。
  • 我正在调查Deployment Rule Sets,但还没有开始工作。另外,这将涉及返回并在每个位置安装它们。

标签: java applet manifest signed-applet


【解决方案1】:

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

【讨论】:

    【解决方案2】:

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

    【讨论】:

    • 我在follow url找到了相关信息。 bugs.openjdk.java.net/browse/JDK-8026347 此错误标记与 JDK-8026228 重复,但我无法查看该错误信息。
    • 除非你会收到更新 21 - 40 的警告。而且你的用户可能还没有更新,再加上公司的愚蠢行为可能会阻止他们在很长一段时间内获得更新 45。
    【解决方案3】:

    不使用 Trusted-Library 和设置:

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

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

    更新:也尝试了 http://... 但也没有用。

    Update2:看起来更糟。我没有更新 7u40(到 7u45),但 Java 控制台(完整调试)显示“LiveConnect 1.7.45”文本。之后,我的 Javascript->Java 调用被阻止

    更新 3:我注意到我的警告显示 Application and Publisher = UNKNOWN。虽然我有:

    Application-Name: MyApplet
    Implementation-Vendor: MyCompany
    

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

    【讨论】:

    • 关于 Update3: 如果禁用了 java 缓存(临时文件),JRE 将无法显示应用程序和发布者的详细信息。
    【解决方案4】:

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

    【讨论】:

    • 作为免责声明,我是 Oracle 产品管理博客上一些帖子的作者,包括上面链接的那个。虽然 * Caller-Allowable-Codebase 有效,并且 ISV 需要它的原因很清楚,但那些可以指定它的人应该这样做。 WhiteHat 的演讲(在 BlackHat)中有一篇文章涵盖了 browser botnets。如果您有网址,请尽您所能提供。
    【解决方案5】:

    我的发现是一样的:

    这可以防止 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 到底出了什么问题?

    【讨论】:

    • 这让我想知道使用 .jnlp 描述符嵌入小程序是否允许您为 7u45 提供一个 .jar 为 7u21–7u40 提供另一个 .jar:<java version="1.7.0_45+"><resources><jar href="MyApp-CodebaseInManifest.jar"/></resources></java> <java version="1.7.0_21+"><resources><jar href="MyApp-TrustedLibraryInManifest.jar"/></resources></java>
    • 确认我必须为更新 45 删除 Trusted-Library。并同意 - Oracle 到底出了什么问题!
    • 不幸的是,VGR 建议的方法似乎对我不起作用,似乎无法指定资源部分只能与指定的 Java 版本一起使用。
    • 同意 rasto - 我也没有找到。什么不工作是这样的:<resources><j2se version="1.7.0_45+" href="http://java.sun.com/products/autodl/j2se"/><!-- NOT WORKING VERSION SELECTION --><jar href="a_45.jar" main="true"/></resources><resources><j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se"/><!-- NOT WORKING VERSION SELECTION --><jar href="a_21.jar" main="true"/></resources>
    • 有没有人发现如何使用签名小程序来避免这个警告?当小程序被签名并且您尝试通过 javascript 访问它时,这两种方法都不起作用。
    【解决方案6】:

    来自甲骨文:

    领域:部署/插件 概要:与 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

    【讨论】:

      【解决方案7】:

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

      所以解决办法是:


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

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

      【讨论】:

      • 它需要使用的是更新 21 到 40,这些更新是在引入了受信任的库属性之后的。在此之前,我完全希望这些属性能够正常工作,因为它们被忽略了。
      • 我无法确认这项工作 - LiveConnect 在 1.7.0_25-b17 上拒绝带有此清单的 JS 调用。一切看起来都很好(没有警告),但它仍然不起作用:(
      【解决方案8】:

      这组属性允许小程序在 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 提供小林丸 - 我们爱你。

      【讨论】:

      • 你的JS是直接调用applet方法吗?对我来说,小程序运行良好,直到页面上的 js 尝试访问方法,然后出现警告。删除 Trusted-Library 确实为我删除了 7u45 中的警告,但你说得对,它可能不是根本原因。
      • @William:是的。 JS 客户端完全通过 API 驱动小程序。
      • 这没有任何意义。如果 JS 调用小程序,则 7u21 需要 Trusted-Library,否则您将收到混合代码警告。您是否更改了设置以不提示您?尝试删除所有 Java 设置并重新测试。
      • @Sarel:很好的收获;我的测试人员已将她的安全级别更改为中 - 她现在正在重新测试高(当然,在非常高时,您总是会收到警告)。
      • @Sarel:她将其设置为中等,因为如果 Java 知道有较新的 JVM 可用,那么当它设置为高时,Java 将不允许您使用较旧的 JVM。令人沮丧。
      【解决方案9】:

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

      【讨论】:

        【解决方案10】:

        我能想到的唯一适用于 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';
                }
        

        【讨论】:

        • 我还得到了两个小程序,并根据检测到的 Java 版本加载它们。似乎是唯一的解决方案。
        【解决方案11】:

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

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

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

        【讨论】:

        • 欢迎来到 Stack Overflow!虽然这在理论上可以回答问题,但最好在此处包含答案的基本部分,并提供链接以供参考。
        • 除非我错过了它,否则我没有看到任何说这将在该帖子中修复。他们只是承认它应该起作用,但没有。有帮助,感谢 Oracle!
        • 在解释可能的属性组合(Trusted-library 和 Caller-Allowable-Codebase)的表格中,他们说:“这将在未来的版本中修复,以便两个属性可以共存。”
        • @vbail 谢谢。我只是重新阅读它并第二次发现它。
        • 使用新版本 1.7.0_55,现在,如果您将 Caller-Allowable-Codebase 设置为“*”,您将看到安全警告。只有第一次,如果你检查不要再看到它。发行说明:oracle.com/technetwork/java/javase/7u55-relnotes-2177812.html
        【解决方案12】:

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

        不幸的是,如果您的应用程序需要访问与运行应用程序不同的目录中的文件,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),但是这些似乎都是围绕 jar 的目的而设计的,而不仅仅是常规文件...

        有什么想法吗?并且由于 Oracle 无论如何都打算解决 Trusted-Library 问题,是否会提出一个(可能)宏伟的变通解决方案来解决这个问题,甚至值得付出努力吗?呜呜呜……

        【讨论】:

          【解决方案13】:

          我现在发现,即使我已正确设置 Caller-Allowable-Codebase,我的一些用户仍会收到此“混合签名和未签名代码”警告(由于 Web 页面中的 LiveConnect 调用小程序),那些得到它和那些没有得到它的区别在于他们是否在客户端主机中启用了applet .jar 文件缓存。那些允许 Java 在客户端上保留临时文件(即,允许缓存 applet .jar 文件)会收到警告,而那些关闭缓存(因为 applet 缓存从来没有完全正常工作)不会收到警告。去图吧。

          【讨论】:

          • 您应该在&lt;object&gt; 中使用cache-version 属性,在其中应用您的小程序。然后你应该手动或在自动构建的帮助下,在每次发布构建之前增加这个值。因此,您不会被客户的“保留临时文件”选项所困扰。
          【解决方案14】:

          我发现 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】:

            如果你制作了一个 Manifest 补丁文件,记得在最后留一个空行,否则它将无法工作。 例如,您可以制作如下补丁:

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

            但是您需要添加一个空行(在示例中是 5 行而不是 4 行!)

            然后将其添加到清单中:

            jar uvfm jarName.jar permissions.txt
            

            【讨论】:

              【解决方案16】:

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

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

              注意:安全警告弹出窗口未使用通配符 * 和 *.com 禁用。

              【讨论】:

                猜你喜欢
                • 2013-11-20
                • 1970-01-01
                • 1970-01-01
                • 2010-09-17
                • 2012-11-03
                • 2014-03-22
                • 2012-05-01
                • 1970-01-01
                • 1970-01-01
                相关资源
                最近更新 更多