web-dev-qa-db-ja.com

Javaアプレットマニフェスト-すべてのCaller-Allowable-Codebaseを許可する

Java 7u45の時点で、Webページがjavascriptを介して対話しようとし、そのページがマニフェストの呼び出し元にリストされていない場合、アプレットは警告メッセージを表示します。 -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

ワイルドカード（*）だけを試しましたが、それでも警告が表示されます。

実行される可能性があるすべてのコードベースをリストする以外に、これを回避する方法はありますか？

これが私にとって問題である理由は、このアプレットが多くの異なるマシンとネットワークで実行されますが、常にさまざまな場所のイントラネットで実行されるからです。このアプレットは、ローカルUSBスケールと通信して結果を表示し、ページと対話するため、javascriptと通信する必要もあります。

Example of warning message

問題のアプレット： https://github.com/JaggedJax/CIO_Scale

javaappletmanifestsigned-applet
65
William W

Trusted-Library属性を削除することは、Caller-Allowable-Codebaseを機能させるために必須であり、これ以上の警告はないようです。ただし、これはJava 7 Update 21-40を壊しますTrusted-Library = true属性を使用します。

26
Nikolas Pooch

私の発見は同じです：

これにより、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バージョンで警告なしに実行できるようにする方法を見つけましたか？

オラクルの何が悪いの？

35
fiffy

Oracleのブログ投稿によると、これは将来のリリースで修正される予定です。

https://blogs.Oracle.com/Java-platform-group/entry/7u45_caller_allowable_codebase_and

「これらの属性の両方が連携して、クライアントインストールのさまざまなバージョンをサポートする必要があります」というエラーを認識します。しかし今のところ、彼らの解決策は次のとおりです。「現在の回避策は、古いTrusted-Library呼び出しよりもCaller-Allowable-Codebaseを使用することです。」

10
vbail

同じ問題がありました。私の解決策は、マニフェストで同じパラメータを使用し、Oracleが確認のためにアプレットのdonwloadページで使用したものと同じJava version http://www.Java.com/en/download/installed。 jsp アプレットは警告をポップアップしません。

解決策は次のとおりです。


マニフェストバージョン：1.0
コードベース：*
許可：すべての許可
Application-Library-Allowable-Codebase：*
Caller-Allowable-Codebase：*
アプリケーション名：APPNAME

動作します：
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18

6
user2886551

oracleから：

分野：展開/プラグイン概要：Trusted-Libraryで使用した場合、Caller-Allowable-Codebaseは無視される場合があります。

信頼され、署名されたjarが、Trusted-LibraryとともにCaller-Allowable-Codebaseマニフェスト属性を使用している場合、Caller-Allowable-Codebaseマニフェストエントリは無視され、その結果、JavaScript-> Java呼び出しは、ネイティブのLiveConnect警告を表示します回避策は、Trusted-Libraryマニフェストエントリを削除することです。

http://www.Oracle.com/technetwork/Java/javase/7u45-relnotes-2016950.html

5
rob2000

7u45およびTrusted-Libraryバージョン（7u21、7u25、および7u40）で動作する唯一の解決策は、異なるマニフェストで2つの異なるJARを作成し、ユーザーのバージョンを検出して適切なものをロードすることです。

メインバージョンは、7u21および7u45以上のバージョンに配信され、新しいCaller-Allowable-Codebaseがあり、Trusted-Libraryエントリはありません。作成される2番目のバージョンには、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を使用してアプレットを起動するため、これを使用して標準アプレットと信頼ライブラリアプレットを決定します。

        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';
        }
3
Sarel Botha

Caller-Allowable-Codebaseを正しく設定しているにもかかわらず、一部のユーザーがこの「署名されたコードと署名されていないコードの混合」警告（アプレットへのWebページでのLiveConnect呼び出しによる）をまだ受け取っていることがわかりました。クライアントホストでアプレットの.jarファイルキャッシングが有効になっているかどうかで、取得するものと取得しないものが異なります。 Javaがクライアント上に一時ファイルを保持することを許可する（つまり、アプレット.jarファイルをキャッシュできるようにする）ものは警告を受け取り、キャッシュをオフにするものは（アプレットのキャッシュがまったく機能しなかったため右）警告は表示されません。

2
Larry

アップデート1.7.0_25（およびおそらく21-40）の場合、Java [コントロールパネル]-> [セキュリティ]タブでセキュリティ設定を[中]に設定すると、アップデート1.7.0_45のマニフェストタグを使用する際のプロンプトが削除されます。

2
englebart

私は同じ問題を抱えていたので、MANIFEST.MFからTrusted-Library = trueを削除し、Caller-Allowable-Codebase属性を正常に動作させます。

2
user2885326

この属性セットにより、アプレットはJava 7u45：

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

次のJVMでテストしました。

  • Java 6u20（OK、まあ！）
  • Java 7u21 -警告を回避するためにTrusted-Libraryを含める必要があります
  • Java 7u25 -警告を回避するためにTrusted-Libraryを含める必要があります
  • Java 7u40 -警告を回避するためにTrusted-Libraryを含める必要があります
  • Java 7u45

長いことと短いことには、ジレンマがあります。 7u21、7u25、および7u40で警告を表示しない場合は、Trusted-Library：trueを含める必要があり、7u45で警告を表示しない場合は、このプロパティを省略する必要があります。

小林丸のOracleに感謝します-私たちはあなたを愛しています。

2
Lawrence Dol

Java 8 Update 45 JREを使用して、この「セキュリティ警告」ポップアップおよびその他の関連ポップアップを無効にするには。

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

注：ワイルドカード*および* .comでは、セキュリティ警告ポップアップは無効になりませんでした。

1
Saju Panikulam

Trusted-Libraryおよび設定を使用しない場合：

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

私にはうまくいきませんが、まだ警告が表示されます。

更新：http：// ...でも試してみましたが、どちらも機能しませんでした。

pdate2：さらに悪いようです。 7u40を（7u45に）更新しませんでしたが、Java console（完全デバッグ）に「LiveConnect 1.7.45」テキストが表示されます。その後、Javascript-> Java呼び出しがブロックされます。

pdate：私の警告がApplication and Publisher = UNKNOWNを示していることに気付きました。私が持っていると思った：

Application-Name: MyApplet
Implementation-Vendor: MyCompany

私が使用していたJDK7u5の代わりにJDK7u45を使用してみました。

1
helpCrypto

最後のJava新しい属性「Caller-Allowable-Codebaseのセキュリティ問題」の範囲内でMANIFEST.MFファイルに奇妙なことが見つかりました。この新しい属性は役に立たず、調査を開始しました
（注意 !:ローカルコンピューターの構成にのみ関連している可能性があります-stackoverlowでこのような問題が発生したことは一度もなかったためです）。

マニフェストファイルは、新しいセキュリティ機能に従ってアップグレードされました。

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

および* .jarはビルドされましたが、without署名。

そこで、私はnpacked my * .jarファイルを探し、MANIFEST.MFのMETA-INFフォルダーを探しました。このフォルダーで、ソースmanifest.mfが生成されます。

そして、私は最後の行がないことに恥ずかしかった、それはこれに見えた：

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

私はこの動作を数回テストし、最後の行が常に空白に交換されることを発見しました。したがって、誰かに役立つ場合は、MANIFEST.MFファイルの最後に、*。jarのビルド中に切り取られるCodebase: *などの意味のない属性を追加するだけです。

0
rock_walker

マニフェストパッチファイルを作成する場合は、最後に空行を忘れないでください。そうしないと機能しません。たとえば、次のようなパッチを作成できます。

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

ただし、空の行を追加する必要があります（この例では4行ではなく5行です！）

そして、それをマニフェストに追加します。

jar uvfm jarName.jar permissions.txt
0
Laura Liparulo

EDIT：判明したように、ファイルが別のディレクトリにある場合、アプリは別のことを行っていました-具体的には、アクセスしようとしていませんでしたアプレット署名jarマニフェスト。そのため、ファイルが別のディレクトリにあるという事実は無関係でした。そのため、以下の情報は正確ではありません。新しい質問で警告の本当の理由を詳しく説明することにしました： Java 7 update 45、警告をトリガーしないとマニフェスト情報を参照できなくなりますか？

残念ながら、アップデート45の問題を回避するためにOracleや他の人が提供する回避策は、アプリが実行されている場所とは異なるディレクトリのファイルにアクセスする必要がある場合は機能しません。

私のWebスタートアプリでは、7u21に追加する必要がある「Trusted-Library」属性を使用して、すべてがうまく機能しました。 7u45では、「Trusted-Library」属性を削除し、他の回答で説明したすべての追加属性を追加しても機能しません-Trusted-Library属性なしで7u21を実行している場合と同じ警告が表示されます（アプリケーションの統計には、署名されたコードと署名されていないコードの両方が含まれます）。

非常に不可解な理由により、Oracleは最大トレース（レベル5）で実行している場合でも、コンソールに「署名されていない」コードが何であるかの表示を表示しないことを決定したため、これを理解するのに永遠にかかりました。ただし、基本的に、アプリは、ユーザーがアプリケーションのプロパティ（アプリのログレベルなど）を構成するために使用できる構成ファイルにアクセスする必要があります。この構成ファイルは、プレーンテキストファイルです。そして、設定ファイルを、アプリの実行元と同じ場所にあるディレクトリに保存します：..\config\app.properties。このファイルには、メインjarの初期化ルーチンの一部としてアクセスします。ここで警告が発生します。

ここでの回避策は？ app.propertiesを、アプリが実行されているディレクトリと同じディレクトリに移動します（jar内の参照を「app.properties」に変更します）。出来上がり、機能します-警告はもうありません（前述のコードベース属性を使用している限り）。一体何のオラクル？

残念ながら、アプリはユーザーごとにカスタマイズされた設定ファイルを許可するため、アプリの起動ディレクトリに設定ファイルを置くだけでは簡単ではありません-それはユーザーごとにカスタマイズされていないため、マシンごとに1人のユーザーのみがアプリを同時に使用できるようにすることができます。

Javaのマニフェストのドキュメントを調べて、このファイルを読み込んでも警告が表示されないように、構成ファイルディレクトリを「安全」にする方法があるかどうかを確認しています。私が考えることができる唯一のことは、クラスパス属性または拡張属性の組み合わせを使用できることです（ http://docs.Oracle.com/javase/7/docs/technotes/guides/ plugin/developer_guide/extensions.html ）、ただし、これらはすべて、通常のファイルだけでなく、jarの目的に合わせて設計されているようです...

何か案は？ Oracleはいずれにせよ、Trusted-Libraryの問題を修正するつもりであるため、この作業の価値があると思われる（潜在的に）壮大な回避策を考え出していますか？ Grrr ....

0
Jon

私たちにもこの問題がありました-クライアントが更新されたJREプラグインを持っていないかもしれないという理論に基づいて、1.4.2でビルドしていました。新しいマニフェスト属性を入れましたが、1.7_u45 JREでポップアップ警告が表示されました。 1.6でリビルドしましたが、警告は消えました。

0
Marc Schabb