Years ago I wrote a Java Web Start application in NetBeans that performs a simple file upload task. For years I had it as a self-signed applet but finally caved and bought a signing certificate. I've got it all signed now, but I'm running into a new problem.
One of the main class' public methods gets called by JavaScript. However, it seems to have stopped working. When I try calling this method manually in Firebug, here's the message I get back:
Error: Liveconnect call for Applet ID 8 is not allowed in this JVM instance.
UPDATE: Here's the version of the error that I get when I try this in Chrome:
Error calling method on NPObject.
I am already using the most up-to-date version of the Java plugin (7u51), so what gives? This applet used to work, but now apparently it no longer does. Do I need to add something special to the code? Or change a setting in the way it's compiled by NetBeans?
I figured it out; I found some forum posts that mentioned I had to update my Manifest file. Apparently Oracle recently changed the way Liveconnect works so you have to be explicit about allowing subdomains that can call the applet.
The information on that is here, and basically you have to add the Caller-Allowable-Codebase directive to the Manifest file. Fortunately it can be set to a wildcard, which is what I ended up doing. Apparently you're also supposed to set Application-Name along with it in the manifest file, and you're specifically NOT supposed to include Trusted-Library true. I don't really know why or what that does, but I was able to adjust my manifest file and everything seems to work again!
Related
I've been quite happily signing my jar files for a year or so and had no issues whatsoever, but very recently I have noticed that I'm getting the warning below.
Now, nothing has changed, I'm not creating anything different, my certificate is valid, I'm signing in exact same way, same JDK and same JRE and I'm uploading to the same location and so on so kind of hitting a wall.
I've tried running from a different computer, different OS and JRE, all with same outcome.
What I have also noted though and find this particularly strange, is that even if I add a site exception, I still get the same error.
Are there any logs or can such logging be enabled to find out exactly why the applications are not being allowed to run?
My issue was caused by mismatched information in the manifest file inside the jar and the jnlp file, my own oversight as it happens. The CODEBASE and PERMISSIONS differed, not quite sure how that happened but guess it makes sense for java security to not allow such an application to run with said differing information.
I've noticed a curious thing while trying to dynamically generate JNLP files based on URL parameters passed to a HTTP server. If I have something like this in my HTML code, it works:
<embed type="application/x-java-applet;" launchjnlp="dummy.jnlp"/>
If on the other hand I have a % character in the launchjnlp attribute, the plugin simply won't do anything:
<embed type="application/x-java-applet;" launchjnlp="dummy%3f.jnlp"/>
No error messages, no default Java splash screen, nothing, it silently fails. (Without even attempting to retrieve the JNLP file.)
Is this some kind of security feature? If it is, what is it supposed to guard against?
Or could it be a straightforward bug?
Update: Using the % entity instead of a % sign doesn't work either.
Update 2: I tried and failed to find any documentation on the exact semantics of the launchjnlp attribute, but the entire tag is generated by deployJava.launchWebStartApplication(jnlp), which is supposedly the "official" way of launching a Web Start application from a browser.
Update 3: Just to be absolutely crystal clear about this: the above example is just that: an example. You can observe the described behaviour with absolutely any URL (relative, absolute, file://, http://, you name it), any url-encoded character, or even an invalid escape sequence (though in that case it's more or less justified), the existence or absence of an actual JNLP file is irrelevant, because we don't even get to the point where the plugin would attempt to load the JNLP file.
Is this some kind of security feature? If it is, what is it supposed
to guard against? Or could it be a straightforward bug?
From what I can uncover, 'straightforward bug' is the answer. Here's the issue page:
https://bugs.openjdk.java.net/browse/JDK-8043409
It looks like it's not scheduled to be fixed until the release of JDK 9.
I'd suggest trying a different JDK implementation, but that seems unlikely to change anything given the amount of code shared between the Oracle and OpenJDK implementations and the fact that the WebStart code appears to be proprietary/closed-source.
So the workaround you devised with base64-encoding is probably the best option for now. If you have to do this often, maybe the encoding step can be rolled into the deployJava.launchWebStartApplication(jnlp) JavaSript API so that it happens automatically if/when needed.
In particular - the Applet.class. How could I find where it locally resides? I have tried the following, but I get an exception:
System.out.println(JApplet.class.getProtectionDomain().getCodeSource().getLocation().getPath());
It is of course somewhere in Program Files/Java/jdk_7_xx/ but I have had quite a look around and searched online and cannot find the answer. I have always wondered where specific classes reside on the system.
Note: If you want some more detail (not necessary to read below this):
What I specifically want to do is edit the Applet.class and point my Eclipse to a new JRE System Library that contains the edited Applet.class. In theory this sounds plausible, yet in practice I am unsure.
This is needed so I can test legacy code which keeps making calls to super methods - I have tried many frameworks/approaches and tried multiple possible solutions that have been posted on stack overflow and other online resources - none work.
Found the JApplet.class in C:\Program Files (x86)\Java\jdk1.7.0_25\jre\lib\rt.jar
Made a back-up of jdk1.7.0.25 on my desktop and put it in a folder Desktop\BACKUP\jdk1.7.0.25
Unzipped it (rt.jar), decompiled Applet.class with jad, changed some methods and even added a new one, recompiled it, rezipped it, replaced the old rt.jar with the new one, made a new eclipse project and made it use the JRE in Desktop\BACKUP\jdk1.7.0.25 and it worked perfectly.
..do you know how I can find the specific path of the Applet.class?
For your own PC? Sure. For the PC of a client of your applet? No.
In fact, Oracle (or was it Sun?) eventually decided it was not the business of an app. launched within the Java Plug-In (e.g. applets or JWS apps), to know where the classes were cached. Not even it that app. was fully trusted.
I'm assuming its in a jar somewhere?
Don't assume. It is set in the Java Control Panel, which defaults to 'no compression'.
I'm reading pdf files with python. And in my script, i'm calling a jar file by command line using os.system.
Two things here:
OSX annoyingly keeps redirecting me to desktop everytime the jar is called. I can optmize that, but I don't want OSX to do that; and
Isn't there a way to no actually open java internally ? Like attaching the code inside my python script. Let's just say I don't want the user to see java being opened.
Thanks in advance.
You may want take a look at similar discussion here. To summarize the discussion, you can use Py4J.
There is also another project called JPype, however that seems to be a very old implementation (way back in 2009) and no updates thence.
I have recently put together a JWS application which gets it's argument from a dynamically created JNLP file (details can be found here). It's all good except the application ignores the argument (starts without loading the specified number) on my system (linux x86_64). It seems however that the JWS application exactly as intended on the win_64 machine of a colleague of mine. This is rather interesting as I couldn't replicate his success on another similar win_64.
To make things more exciting, the same JWS application works just fine (in other words, doesn't ignore the argument) when I download the JNLP file and run it by javaws on the terminal.
I have compared the java.policy and javaws.policy files and there are no differences. The JNLP file clearly gives all-permissions, and the jar files are signed all fine (which can't be the source of the problem otherwise the application wouldn't start, right?).
Question 1: So what could this problem depend on?
EDIT: I just managed to get proper response from a new (in this particular sense) win32 machine, without any obvious java update. Question 2 : Is there a log file for javaws on which I can check what happens, or alternatively, can I verbose the launch to a console so I can create my own custom logs?
Edit 2: By the way, I have forgotten to mention that I have also posted this question at the Oracle forums, which I should have perhaps mentioned initially as it was politely pointed out there. Anyways, there is more information on the JNLP file there on the thread, in case it might be relevant.
Edit 3: I came to think that the problem could be originating from the properties of the <jnlp> tag, upon generating the JNLP file. Originally the jnlp tag looked like this like this:
<jnlp spec="1.0+" codebase="http://mydomain/myapp/"
href="my.jnlp">
The problem with this is the fact that there is no my.jnlp in the the directory declared in the codebase, instead the JNLP code is created on the fly by a Perl script in the cgi-bin directory and returned as an output stream (I think). So I edited the script to generate the JNLP with the following tag:
<jnlp spec="1.0+" codebase="http://mydomain/myapp/"
href="http://mydomain/cgi-bin/my.jnlp">
The result of this experiment: not even the GUI started this time...
I have found a relevant thread on Oracle forums, where it was advised to define the href property in the following fashion:
href="script.jsp?<%=request.getQueryString()%>">
which unfortunately doesn't solve my problem.
Question 3: Could this modification be applicable to my situation as well? In that case how? If not any insights on what might be causing the problem would be seriously appreciated as I am really at a stalemate on my work right now
After two weeks of wrestling with the JNLP file syntax and my CGI script, I think I finally found the crux of the problem. I am noting this down here (at the risk of looking pretentious enough to answer my own question) in case somebody else runs into the same problem.
The href property of the <jnlp> tag, in my case was apparently unnecessary and when removed the application started working as intended on both linux and win systems. I am not 100% sure if this is the exact reason but my understanding is that as the jnlp syntax is generated from a script and directly returned to the user instead of a jnlp file somewhere in the filesystem, the href property was pointing to a wrong place and perhaps caused some sort of a clash that is handled differently in different OS.
Make sure the JNLP file is not cached. I.e., each time you try something new, have you renamed / relocated the JNLP file?
Regarding your updates,
The only ting that comes to my mind is that you need to make sure that your script responds with the correct mime type: application/x-java-jnlp-file
That is, from your cgi-script, you have to provide the HTTP header field
Content-Type: application/x-java-jnlp-file