Develop Reference

Unable to access file in hard drive using Apache Tomcat server

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.

What are the privileges or rights a client could get with the static resources (css/javascript files) on a typical java web server?

Ok, I'm a beginner so this maybe stupid but i afraid that clients can modify static resources (css/javascript files) on server if they can load them directly through URL path (Of course I have to put css/javascript files outside of WEB-INF folder).
If my hypothesis is wrong, could you give me links or quotes to help me expand my knowledge ? Thank you :)

When a user's browser requests resources from your server, they are performing a GET request. This request will not directly change any file on your server. The request will go through your web server and will be processed. In the case of the resources such as css/javascript files, the web server sees the user is requesting the file and sends the contents of the file back. There is no way the user can update the contents of those files on the server unless you write code on the server to allow them to update the files. If the user has direct access to the server via ssh or other protocol and has permissions on the folder that holds the resources, they would be able to change them.
The whole process is much more complex for going through the web server, but for brevity left out here. Here is a good article that explains what really happens when you go to an address in a browser:
https://medium.com/#maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a

Java Web Start uses a different cache directory

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.

Can not start Java Web Start on a protected site

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.

HTML5 local storage offline cache is not working in Google AppEngine app

i'm trying to use HTML5 local storage offline cache to store images locally but unable to cache it properly, im using manifest configuration in my HTML, here is the sample code for it.
in server i have created "test.appcache" file with below configuration.
CACHE MANIFEST
/images/.
but it is unable to cache content locally, if i see the network tab in chrome/firefox the status code of images were 304 with offline cache configuration and without this configuration. my application is landed in Google AppEngine platform.
Please let me know where it went wrong.
Thanks in Advance!

Just creating a manifest isn't enough - you have to make sure you're serving it up (by adding it as a static resource in your App Engine configuration), and reference the manifest from your HTML, as documented here.

I struggled with same issue and finally got it to work. Needed to add both of these handlers to app.yam. Also note that Chrome console will automatically debug your appcache - big help.
runtime: php55
handlers: