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
Related
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.
I'm getting an error in my program about a class not being found. I have double (and triple) checked and the class is definitely in my jar - it's finding other classes from the same jar just fine.
To help with debugging this, I want to turn on verbose class loading logging as described here:
http://java.dzone.com/articles/how-use-verbose-options-java
That doesn't say how exactly to turn on this option if you're using WebSphere Liberty Profile, though, so I looked around some more and found this:
http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_admin_customvars.html
This says that I need to place the line in ${server.config.dir}/jvm.options.
So I wrote a simple file which consists only of:
-verbose:class
And I saved that to wlp/usr/servers/defaultServer/jvm.options, which means the new file is in the same directory as my apps folder, my logs folder, and my server.xml.
I stopped my server and started it back up and looked in the logs directory. It generated the same logs as always, nothing new: console.log, messages.log, status.log, and trace.log. I checked all of these log files and none of them have anything like the output from my first link.
So I don't think I'm doing this properly. Here are the three points where I think I may have gone wrong:
Was my file too simple? Is there more that I need to put in it than just -verbose:class? Does that perhaps need to be nested in something? Are there more parameters that I must have? Prior to this I didn't have any jvm.options file at all, so I assume that it'll use default values for anything I'm not explicit about.
Did I put the file in the proper place? As far as I can tell from the documentation, I think I put it in the proper spot, but the docs are a bit less explicit than I would like.
Am I looking in the right place for the logs? What will the name of the log file be? Where will it be placed? I assumed it would be in the logs directory just like all of the other logs generated by WebSphere Liberty Profile, but maybe I'm incorrect?
While writing the third bullet for my question, I realized that console.log was actually a new file that didn't previously exist, and I hadn't actually checked what was in it. I just opened it up and lo and behold, it's exactly the class loading logs that I was looking for.
So to recap, here are the answers to my bullets:
You can have a file with nothing but -verbose:class
You save it to wlp/usr/servers/<server name>/jvm.options
The output is in wlp/usr/servers/<server name>/logs/console.log
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!
I want to get the absolute path of my app and I'm using the code below:
String pathToSave = FacesContext.getCurrentInstance()
.getExternalContext().getRealPath("/");
the result is:
/home/ronaldo/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/Odontonew/
But I'm waiting for something like: /home/ronaldo/workspace/Odontonew/
What is wrong ?
ExternalContext#getRealPath() returns the path relative to where the webapp is been deployed, not where the webapp is been developed orso, as you incorrectly seemed to expect.
But, the variable name pathToSave indicates a much bigger problem: you seem to intend to save files in there. This is a bad idea for the reasons mentioned in the following answer: Uploaded image only available after refreshing the page. In a nutshell, save them to a fixed local disk file system path instead. Note that some servers offer ways to make this step easier configurable, e.g. JBoss.
Just stop using getRealPath(). You never need it in real world. In the 10 years I developed Java web applications (it's under the covers coming from ServletContext#getRealPath()), that method was never been useful for anything. Just ignore that method altogether.
See also:
What does servletcontext.getRealPath("/") mean and when should I use it
Why do I get:
java.lang.NullPointerException org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:53)
when trying to run the 0wasp.CsrfGuard.Test example app on Tomcat 5.5?
I'm using the example app exactly as it came in the download but with the following changes to get around listener errors:
I downloaded the CsrfGuard 3.0.0 package and copied the Owasp.CsrfGuard.jar to WEB-INF/lib to get around the listeners not being found.
I changed the web.xml file to use the listener that comes with the Owasp.CsrfGuard.jar rather than the two listeners in the original web.xml, which don't exist.
When I start the app there are no errors but when I point my browser to the /Owasp.CsrfGuard.Test/index.html page, I get the above error.
Any ideas to try?
Update...
Several hours later and I got it working without error. I don't understand why but the filter errors seem to stick around even after stopping and restarting a webapp (in Tomcat at least). I had to rename that webapp's directory, wait 10 seconds for Tomcat to auto-undeploy it, rename it back to its original directory name, and wait 10 seconds for Tomcat to recognize it as a new webapp. I also removed the "x-requested-with" init-param from the web.xml file since I don't use AJAX. Don't know if that really needed to come out but it works so I'm leaving it out.
Now, the "protect.html" file is indeed protected but it is protected too well. I can't get to it at all. If I try to go directly to the protect.html page, it should not allow that, which it doesn't. However, it should allow me to get there through the proper webpage flow with all the pages getting the proper token(s).
The question now is how can I get to the protect.html page?
Thanks.
Got it! In case someone else has problems, here is what I figured out to get JavaScript DOM Manipulation working.
All of the references in the .properties file MUST BE absolute with reference to the web container (Tomcat in my case). Even if you place the .js and .jar files in a specific webapp and modify that webapp's web.xml file with the proper settings for CSRFGuard (with relative references by the way), the entries in the .properties file must include references to the webapp name. For example, it must be something like:
org.owasp.csrfguard.unprotected.Index=/someapp/index.html
rather than just
org.owasp.csrfguard.unprotected.Index=index.html
This is not intuitive since unless you are dealing with the entire Tomcat container (i.e. the master web.xml file) you can generally drop the webapp name since it is implied for that webapp.
Now I'm going to look into the other CSRFGuard method of JSP Tag Injection since the JavaScript mechanism won't work if the user has JavaScript turned off in their browser.