Java applet manifest - Allow all Caller-Allowable-Codebase

Question

As of Java 7u45 an applet will display a warning message (even if signed with a trusted cert) if a webpage tries to interact with it via javascript and that page isn\'t list

Answer 1

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....

Answer 2

if you make a Manifest patch file remember to live an empty line in the end, otherwise it won´t work. For example you can make a patch like:

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

But you need to add an empty line (in the example 5 lines instead of four!)

And then add it to the manifest:

jar uvfm jarName.jar permissions.txt

Answer 3

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.

Answer 4

This will be fixed in a future release, according to the oracle blog post:

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

They recognize the error "Both of these attributes should work together to support the various versions of client installations". But for now, their solution is: "The current work-around would be to favor using Caller-Allowable-Codebase over the old Trusted-Library call. "

Answer 5

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.

Answer 6

My findings are the same:

This prevents warnings with Java 7u21 - 7u40:

Manifest-Version: 1.0
Trusted-Library: true

This exclusivly prevents warnings with Java 7u45:

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

Mixing both won't work in 7u45.

Now what? Did anyone find a way to allow SIGNED applets with "all-permissions" to run without warnings in both JRE-versions?

What the hell is wrong with oracle?