Java 애플릿 매니페스트-모든 호출자 허용 코드베이스 허용

Java 애플릿 매니페스트-모든 호출자 허용 코드베이스 허용

---

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

와일드 카드 (*) 만 시도했지만 여전히 경고가 표시됩니다.

실행될 수있는 모든 코드베이스를 나열하는 것 외에 다른 방법이 있습니까?

이것이 나에게 문제가되는 이유는이 애플릿이 다양한 시스템과 네트워크에서 실행되지만 항상 다양한 위치의 인트라넷에서 실행되기 때문입니다. 또한이 애플릿은 로컬 USB 스케일과 통신하고 결과를 표시하고 페이지와 상호 작용하기 때문에 javascript와 통신해야합니다.

문제의 애플릿 : https://github.com/JaggedJax/CIO_Scale

---

Caller-Allowable-Codebase가 작동하도록하려면 Trusted-Library 속성을 제거하는 것이 필수 인 것 같습니다. 더 이상 경고가 표시되지 않습니다. 그러나 이것은 모든 권한으로 실행되는 서명 된 애플릿 내에서 코드를 호출하는 JavaScript 코드를 혼합 코드로 처리하는 Java 7 업데이트 21-40을 중단하고 서명 된 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: *

두 가지를 혼합하면 7u45에서 작동하지 않습니다.

이제 뭐? "모든 권한"이있는 SIGNED 애플릿이 두 JRE 버전에서 경고없이 실행되도록 허용하는 방법을 찾은 사람이 있습니까?

도대체 오라클이 잘못된 건가요?

---

Oracle 블로그 게시물에 따르면이 문제는 향후 릴리스에서 수정 될 예정입니다.

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

그들은 "이 두 속성 모두 함께 작동하여 다양한 버전의 클라이언트 설치를 지원해야합니다."라는 오류를 인식합니다. 그러나 지금은 솔루션이 "현재 해결 방법은 이전 Trusted-Library 호출보다 Caller-Allowable-Codebase를 사용하는 것입니다."

---

나는 같은 문제가 있었다. 나를위한 해결책은 자바 버전 http://www.java.com/en/download/installed.jsp 확인을 위해 애플릿의 donwload 페이지에서 사용 된 Oracle과 동일한 매개 변수를 매니페스트에서 사용하고있었습니다 . 그들의 애플릿은 경고를 표시하지 않습니다.

그래서 해결책은 다음과 같습니다.

매니페스트 버전 : 1.0
코드베이스 : *
권한 : 모든 권한
Application-Library-Allowable-Codebase : *
Caller-Allowable-Codebase : *
Application-Name : APPNAME

작동 :
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18

---

오라클에서 :

영역 : 배포 / 플러그인 개요 : 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

---

7u45 및 Trusted-Library 버전 (7u21, 7u25 및 7u40)에서 작동한다고 생각할 수있는 유일한 솔루션은 매니페스트가 다른 두 개의 JAR을 만든 다음 사용자의 버전을 감지하고 올바른 버전을로드하는 것입니다.

7u21 및 7u45 이전 버전에 제공되는 기본 버전에는 새 Caller-Allowable-Codebase가 있고 Trusted-Library 항목이 없습니다. 생성 된 두 번째 버전에는 Trusted-Library가 있으며 7u21, 7u25 및 7u40에만 제공됩니다.

다음은 수정 된 매니페스트로 새 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';
        }

---

I had the same issue, So I remove Trusted-Library=true from my MANIFEST.MF, work Caller-Allowable-Codebase attribute fine.

---

For update 1.7.0_25 (and probably 21-40), setting the security settings to Medium in the Java Control Panel -> Security tab removes prompting when using the manifest tags for update 1.7.0_45.

---

This set of attributes allows the applet to load without warnings in Java 7u45:

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

We have tested on the following JVMs:

• Java 6u20 (OK, well duh!)
• Java 7u21 - must include Trusted-Library to avoid warning
• Java 7u25 - must include Trusted-Library to avoid warning
• Java 7u40 - must include Trusted-Library to avoid warning
• Java 7u45

So the long and short is we have a dilemma; to have no warning on 7u21, 7u25 and 7u40 you must include Trusted-Library:true, and to have no warning on 7u45 you must omit this property.

Thanks Oracle for a Kobayashi Maru - we love you.

---

I'm finding now that some of my users still get this "mixed signed and unsigned code" warning (due to LiveConnect calls in the web page to the applet) even though I've set Caller-Allowable-Codebase correctly, and the difference between those that get it and those that don't get it is whether they have applet .jar file caching enabled in the client host. Those that allow Java to keep temporary files on the client (i.e., allow applet .jar files to be cached) get the warning, and those that turned caching off (because applet caching has never worked quite right) don't get the warning. Go figure.

---

Without using Trusted-Library and setting:

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

Doesn't work for me, and i still see the warning.

Update: Tried also with http://... but didn't work either.

Update2: Seems even worse. I didnt update 7u40 (to 7u45) but Java console (full debug) shows the "LiveConnect 1.7.45" text. After that, my Javascript->Java calls are blocked.

Update 3: I noticed my warning shows Application and Publisher = UNKNOWN. Altought i have:

Application-Name: MyApplet
Implementation-Vendor: MyCompany

I tried using JDK7u45 instead of JDK7u5 i was using.

---

To disable this "Security Warning" popup and other related popups using the Java 8 Update 45 JRE.

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

Note: security warning popup was not disabled with wildcards * and *.com.

---

We had this problem too - we were building with 1.4.2, on the theory that clients might not have an updated JRE plugin. Despite putting in the new manifest attributes, we still got the popup warnings in the 1.7_u45 JRE. We rebuilt with 1.6, and the warnings went away.

---

EDIT: As it turns out, our app was doing something different if the file was in a different directory -- specifically, it wasn't attempting to access the applet signed jar manifests. So the fact that the file was in a different directory was irrelevant. So the below information is not accurate. I've decided to detail the real reason for the warning in a new question: As of Java 7 update 45, one can no longer lookup manifest information without triggering a warning?

Unfortunately, the workaround given by Oracle and others here for getting around the update 45 problem does NOT work if your app needs to access files in a different directory than where the app is being run from.

With my web start app, everything worked fine and dandy with the "Trusted-Library" attribute that needed to be added for 7u21. With 7u45, removing the "Trusted-Library" attribute and adding in all the additional attributes talked about in the other answers will NOT work -- I will get the same warning that you would get if you were running 7u21 without the Trusted-Library attribute (stating the application contains both signed and unsigned code).

It took me FOREVER to figure this out, because for very inexplicable reasons Oracle has decided not to print out ANY indication of what the "unsigned" code is in its console, even when running at maximum tracing (level 5). But basically, our app needs access to a configuration file which can be used by the user to configure application properties (for example, the logging level of our app). This configuration file is a plain old text file. And we store the config file in a directory co-located to where the app runs from: ..\config\app.properties. We access this file as a part of the main jar's init routine. It is here where the warning occurs.

The workaround here? Move app.properties into the same directory where the app is running from (and change the reference in the jar to just "app.properties"). Voila, it works -- no more warnings (as long as using the aforementioned codebase attributes). What the hell Oracle???

Unfortunately, because our app allows customized config files on a per-user basis, it is not as simple for us to just put the config file in the app's startup directory -- since that is NOT customized on a per-user basis, we would only be able to allow one user per machine to use the app simultaneously.

I've been looking over Java's manifest documentation to see if there is some way I can make the config file directory "safe" such that loading up of this file doesn't cause the warning. The only thing I can think of is either being able to use the Class-Path attribute or a combination of the Extension attributes (http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/extensions.html), however these all seem designed around the purpose of jars, not just regular files...

Any ideas? And since Oracle intends to fix the Trusted-Library issue anyway, is coming up with a (potentially) grandiose workaround-solution around this even worth the effort? Grrr....

---

I found some strange thing with MANIFEST.MF file in scope of last Java security issue with new attribute "Caller-Allowable-Codebase". I had some issues, why this new attribute wasn't helpful for me and started investigation
(Attention!: it may be related only to my local computer configuration - because I had never seen such troubles over stackoverlow).

Manifest file had been upgraded according to new security feature:

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

and *.jar was build, but without signing.

So, then I unpacked my *.jar file and looked in folder META-INF in MANIFEST.MF, where source manifest.mf should be generated.

And I was embarrassed by absence of last line, it looked this:

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

이 동작을 여러 번 테스트 한 결과 마지막 줄이 항상 공백으로 바뀐다는 것을 알았습니다. 따라서 누군가에게 도움이된다면 MANIFEST.MF 파일의 끝에 Codebase: ** .jar 빌드 중에 잘릴 수있는 의미없는 속성을 추가하십시오 .

---

Manifest 패치 파일을 만들면 마지막에 빈 줄이 있어야한다는 것을 기억하십시오. 그렇지 않으면 작동하지 않습니다. 예를 들어 다음과 같은 패치를 만들 수 있습니다.

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

하지만 빈 줄을 추가해야합니다 (예제에서는 4 줄이 아닌 5 줄!)

그런 다음 매니페스트에 추가합니다.

jar uvfm jarName.jar permissions.txt

참고 URL : https://stackoverflow.com/questions/19393826/java-applet-manifest-allow-all-caller-allowable-codebase