I have a Java Web Start application. My JNLP instructs Java to prompt when there is an update, and create a desktop shortcut.
On UAT site, it works as intended. The shortcut's target will be something like this:
C:\Windows\SysWOW64\javaws.exe -localfile -J-Djnlp.application.href=[https]://[Domain]/[Path to my JNLP].jnlp "C:\Users[User name]\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\21\5819ce55-139863fe"
In Java Control Panel, I can see my application listed in the cache's Applications list. In the Resources list, I can see the entries for both JNLP and JAR files.
But on Pre-production site (using the same client machine), Java will use a different cache folder:
C:\Windows\SysWOW64\javaws.exe -localfile -J-Djnlp.application.href=[https]://[Domain]/[Path to my JNLP].jnlp "C:\Users[User name]\AppData\Local\Temp\tmp_cache2515468182853051613.tmp"
In Java Control Panel, the Pre-Production application is not listed in the Applications list. In the Resources list, I can only find the JAR file but not the JNLP file.
It is because of the missing JNLP in cache, that whenever I launch the Pre-Production version via the shortcut, Java will prompt that an update is available and will re-download the JAR file.
I tried turning on deployment log, but I have no idea what I should look for. I found entries like this:
Wrote URL [https]://[Domain]/[Path to JNLP].jnlp to File C:\Users[User name]\AppData\Local\Temp\tmp_cache3515307480207784226.tmp
But I have no idea why Local\Temp is used over DeploymentCache. The JNLP files of UAT and Pre-Production sites are nearly identical, the only differences are a change in the title element and contents in properties files.
Another difference I can think of is the server certificates - the JNLP and JAR files are hosted on Apache servers. Java will show a dialog for the Pre-Production certificate, saying that it failed to check CRL. I tried disabling CRL checking and the dialog went away, but it's still using Local\Temp instead of DeploymentCache.
What can be the reason behind this behavior of using different cache locations? It is almost like Java found something untrustworthy about the Pre-Production version and refused to cache its JNLP.
Edit: In a nutshell:
Same client machine, same settings.
Load UAT version of the application, JNLP and JAR gets cached in DeploymentCache folder (expected behavior).
Load Pre-Production version of the application, only JAR gets cached in Local/Temp folder, JNLP is not cached (unexpected behavior).
Only differences between UAT and Pre-Production versions are that they have different title in JNLP, properties files with different content, and that the Apache server hosting the Pre-Production version is using a certificate that Java can't check its CRL. Application JAR is signed by a different certificate that Java has no problem validating.
I would like to know what influence Java Web Start to behave like that. I suspect it has something to do with the certificate on the Apache server, but I can't find any documents about that.
Have you looked into deployment.user.tmp property in deployment.properties ?
http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/properties.html
As per Applet stopped working with a JNLP MissingFieldException <jnlp> see the cookie information to understand if Httponly is contained within it -- looks like it can cause this behavior with jws.
Alternatively this actually worked for me specifically...
In a browser, access the same exact resource from lower and upper environments and inspect the HTTP headers to see if there are any Cache-Control (no-cache and/or no-store directives) or Pragma: no-cache differences. Suspicion is that the environment that is not working has caching directives explicitly specified which, as per first comment of Java Web Start "Cannot find cached resource for URL" and first comment of https://bugs.openjdk.java.net/browse/JDK-8034978, happen to cause java web start to write to a different cache folder than what is specified in java configuration settings and, ultimately, causes the behavior discrepancy you're seeing. The fix would be to update the app server, web server and or any other intermediaries (eg. load balancers) to remove it from the http response headers.
Related
I'm fairly new to using Tomcat so I'm sure I'm missing something.
I have managed to run Tomcat on Ubuntu 18.04 and opened up the manager page, added a .war file which extracted perfectly and got displayed in the manager page(running=true)
However when I try to open up the app from the browser using the exact path it returns a 403 forbidden error with this in the description The server understood the request but refuses to authorize it.
What do I do to get it working
I have tried chown tomcat8:tomcat8 <foldername> and when I tried to refresh the browser the error message changed to 404 not found.
This is likely not a filesystem issue. What is most likely happening is the application requires authentication. Couple of ways to determine this... the best is to read the documentation. You can also look at the source code. Unzip the war and look in the WEB-INF directory, and you should see a web.xml. In that you'll see a security-constraint and roles sections. You'll need a user with those roles.
Tomcat can authenticate against a local database. In the conf directory, there will be a tomcat-users.xml you can add users to (there is examples in that file). Once you've created users, restart tomcat and try logging in with one of those users.
I'm developing local-only JSP application using Apache Tomcat server. I would like to put a promotion videos on my intro page, but I don't want to move them to webapp folder or anywhere else.
The promotion videos are located:
E:\data\videos\2018...
But writing a JSP/HTML like this wont launch the video, but however it works off-server (launching html from desktop for example, so the path may not be issue?)
<video src="file:///E:/data/videos/2018/promotion1.mp4" controls></video>
Local file links from remote resources are disabled by almost all browsers by default. There are certain possibilities to overcome that, e.g.:
http://kb.mozillazine.org/Links_to_local_pages_do_not_work
https://discourse.mozilla.org/t/opening-links-to-local-files-file/16449/2
To access your static media files from remote page you need to configure your Tomcat server as described here: http://teknosrc.com/access-local-files-static-content-images-videos-media-files-outside-web-application-system-apache-tomcat-server/
solution:
a.) make sure your server is on the same system where the media files are.
b.) If so, you have to create a folder (ex. media) in your application folder inside /src/main/webapp/ and have to put all media files inside a media folder. After that, you can surely access the media files through a server.
I have a Web Maven project that uses SmartGWT. After doing maven install, several *.ds.xml files are created in the install folder under sc/schema subfolder. These files are:
DataSource.ds.xml
DataSourceField.ds.xml
DataSourceStore.ds.xml
DBListDS.ds.xml
DBSchema.ds.xml
JVMClassTreeDS.ds.xml
QuartzJobs.ds.xml
QuartzScheduler.ds.xml
QuartzTriggers.ds.xml
SchemaSet.ds.xml
SimpleType.ds.xml
Validator.ds.xml
WebService.ds.xml
WebServiceOperation.ds.xml
WSDLMessage.ds.xml
WSOperationHeader.ds.xml
XSComplexType.ds.xml
XSElement.ds.xml
They can be accessed via browser at my website link my_site/*.ds.xml, which the browser display a red error message. I have searched around and found nothing related to accessibility via browser of these files.
How do I restrict access to these files? Will the pose any vulnerability issue? Is it safe to let them be?
Thanks
It is perfectly safe to leave those files accessible.
In fact the application may need to access them from the client site to function correctly.
I'm trying to access a Java web application using the fully qualified domain name. It accesses the site, but loads only some components, excluding the help and login menus.
However, if I replace the FQDN with the server name, it loads everything.
a) http://fully-qualified-domain-name.example.co.nz/home
This DOESN'T work.
b) http://server-name/home
This DOES work.
Points to note:
1) The symptoms mimic those of "potentially unsafe components" being blocked, however no warning pops up for this despite being enabled in the Java Control Panel.
2) I have added the site to browser security exclusions. No difference with or without.
3) I have the correct JRE installed.
4) No proxy server is being used.
I have the following problem. In one server, I have a folder /protected/ that requires authentication using a SAML token.
When I try to access resources in this folder, I get redirected to a log-in page first, and after login I can access the resource.
Now, I added a .jnlp file inside the /protected/ folder with all resources required. When I try to access the .jnlp file, I get the login page as expected. After logging in Java Web Start initializes and tries to download the resources.
However, Smart Start fails immediately, complaining that it couldn't parse the .jnlp file. When I look into the debug console, I see that Java downloaded, instead of the jnlp file, the log-in page. So it seems that the Java Web Start application does not share the credentials of the browser, so it requires a new log-in
My identity provider is ZXID, and we are using SAML. I would assume that Java Web Start must somehow use the same SAML token as the browser, right? Is this correct? is it possible?
So far in my investigations, it seems that when the browser finds a .jnlp file, it starts Java immediately and the Java Application will try to download the jnlp, creating this issue. I did find out that the JNLP file must not contain the codebase entry. Otherwise the Java VM will try to re-download the file, but because it is not authenticated it will get the login page.
However, if the JNLP can be read, the resources can not be in the protected area either, because again JWS is not authenticated.
So I guess what is needed is that the JWS VM somehow gets the session id from the browser, so it is considered Authenticated.
Any ideas?
So far, I haven't found a proper solution to this problem. I did the following, and it worked:
Created a protected area on my server, and added a servlet behind it
My servlet creates a JNLP file on the fly, with a session id.
JNLP file is used to download the JARs from a public location
The session id is used by the web start application to load resources from the protected area.