How can I make the browser of a client load the new version of the html page with a new java applet?
We updated a system in the field, but when the client connected to the web server, the old java applet was still shown (from the cache).
How can I force (preferably from the server side) the client to load the new version instead of the one from it's cache?
Old system (before upgrade) :
old linux version (more than 10 years old)
old apache webserver (more than 10 years old)
old java applet (separate class files) (about 2 years old)
old index.html in webserver root dir (about 2 years old)
New system (after upgrade) :
same IP address and port as the old system
windows xp embedded
apache/2.2.21 (win32) webserver
new java applet in jar file (all different class names from the old version)
new index.html in webserver root dir
The user is using Chrome on a Windows XP machine
When the user loaded the page in Firefox, the new java applet was shown and working flawlessly. (He never loaded the old java applet in firefox)
[EDIT]
adding the lines from looper to my httpd.conf did not lead to any errors, but i am not sure if it works either ...
i don't seem to be able to reproduce the caching problem of my client : when i change something the in the applet and load it again from another computer, then nothing changes, but when i reload a few minutes later, it does show the new version .. without or without those extra lines with CacheDisable
when i search my httpd.conf for "cache" then all i find is :
#LoadModule cache_module modules/mod_cache.so
#LoadModule disk_cache_module modules/mod_disk_cache.so
#LoadModule file_cache_module modules/mod_file_cache.so
#LoadModule mem_cache_module modules/mod_mem_cache.so
so it seems no caching is enabled ?
when i add the line with CacheDisable by itself (without IfModule), then Apache doesn't want to start, so it probably corrupts httpd.conf ?
[EDIT2]
as the server OS, web server, java class names, and all filenames except index.html are different from the old version, it must be the cached index.html which is the cause of the problem.
I added the meta tags from FrancescoMM's answer to my index.html, and hope this will prevent the problem for future releases
If the java classes are different, then the index file is the one that is in cache. It could also be the client proxy cache, so acting on the server has no result.
The fastest solution is to send a new url to the client:
http://www.site.com/index.html?random_param=1234
http://www.site.com/?random=1234
http://www.site.com/?1234
http://www.site.com/?new
or even just
http://www.site.com/?
should be enough.
EDIT
Also, have you tried adding all the pragma no cache and expiration date meta tags to the HTML page? That should tell the client proxy to reload the page anyway.
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
<META HTTP-EQUIV="EXPIRES" CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">
Note that EXPIRES is set to an old date on purpose. This may not solve your problem this time, as if the new index is not loaded, nobody (server, proxy, client) will see the new tags, but will make sure the next time the page is loaded every time.
Unless you put functionality that allows the applet to invalidate itself based on a server instruction, you'll have to do reset from the client side. Clearing the cache on the browser should do, from the information provided. Every browser has a way of clearing its cache. I don't believe there's a shorter way than that.
Every system turns into a legacy system the moment it's first deployed. It's always a good idea to plan for upgrade. At the very least, any applet that does server communication should report its version number to the server, enabling the server to reject service, start upgrade, notify the user, or whatever else is appropriate.
Just force no-cache in Apache in the httpd.conf.
From the apache-docs:
<IfModule mod_cache.c>
CacheDisable /local_files
</IfModule>
Instead of disabling cache for all local files, you can specify the complete path to the applet-file.
Related
I have an angularJS application with springboot and it runs on 8090 port number with "index.htm" file. Like below ;
192.168.1.25:8090/index.htm
I just googled about the changing port and I did the change with 80 port number so I can open the web page with
192.168.1.25/index.htm
But, in google there are plenty of angular result and they tell me to change those settings with in angular.json file. I created a temporary angular project and did those with successfully. But, I could not figure out about the angularjs part. I checked the project and I could not find any file like angular.json. After that checking the springboot, I found this part of where I can open the web page with the above second URL address ;
192.168.1.25/index.htm
The code of Spring Boot part is below (There is where I can change the port number) :
Those ones did the trick by the way.
config.getMemberAttributeConfig().setStringAttribute(ServerService.MANAGEMENT_URL_PREFIX, ":80/index.htm");
config.getMemberAttributeConfig().setStringAttribute(ServerService.MANAGEMENT_URL_PREFIX, ":80");
After those steps, I can easily serve my angularjs app on 80 port and start to thinking about editing the /etc/hosts file on the server machine as :
192.168.1.25/index.htm xyz.com
I did reboot when I finished the editing part and I tried again to write xyz.com on firefox browser it does not go to my application.
I am still looking on the google and still could not find any solutions about this problem.
Any help will be really appreciated.
Format for hosts file is
#<ip> <hostname that resolve to the ip>
192.168.1.25 xyz.com
# or a list of names
192.168.1.25 xyz.com myapp.xyz.com
You do not put any port numbers or path parts in it. This will obviously only work if you edit the hosts file on all the computers
you are indending to access the site from and not necessarily on the host running the application itself.
That being said, you should probably read on supported Spring Boot properties because starting an application server on a specific port should be as easy as adding application.properties file in java resources with the following line:
server.port=80
I am working in bigbluebutton 0.8.1. I had setup the development environment in my local(ubuntu 10.04) and desktop sharing is working fine.
Later i created new bbb-desktop-applet jar, using the url https://code.google.com/p/bigbluebutton/wiki/081DevelopingBigBlueButton#Developing_Deskshare. And then moved the newly created jar to this location var/www/bigbluebutton/client in ubuntu machine and then restarted the server. I can able to create and join the room, but not able to share my desktop, getting below error. Already I added the url in exception site list in java control panel but still it is not working.i stuck up with this issue.
I'm one of the developers of BigBlueButton.
You need to sign the modified desktop sharing jar file with a valid code signing certificate (not a self-signed certificate); otherwise, the browser will give you a very strong warning (such as the above) that warns the user they are trying to run an untrusted applet.
This is not a security issue with BigBlueButton; rather, it's the absence of a valid certificate signature with your modified desktop sharing applet.
Regards,... Fred
Hi all Java/Applet gurus,
I've stumbled upon an interesting problem with the latest JDK build (1.8.0_b26).
When running Sandbox Java Applet with the latest JDK, from within Java code we try to connect back to the server with a different protocol - instead of original HTTPS we use WSS (secured Websockets connection, we use third party Websockets Client Java library). As the result, JVM tries to retrieve crossdomain.xml file from the server. The problem is, that the file is retrieved using HTTP (and not HTTPS) protocol.
For example, in our case the server IP is 192.168.1.1, the applet is loaded over HTTPS default port (443). Using trace level 5 in Java console we see that the crossdomain.xml is retrieved from http://192.168.1.1:443. And of course it doesn't work because the server listens only for HTTPS connections on port 443 (and not HTTP).
On the other hand, when we use HTTP protocol and open new WS (unsecured Websockets connection) to the server, the problem doesn't appear, because crossdomain.xml is retrieved from http://192.168.1.1:80 and it is completely correct.
As the problem was further investigated, we've made few more observations:
It is possible to provide alternative location of crossdomain.xml file using jnlp.altCrossDomainXMLFiles Java VM parameter. We've never succeed to make this parameter work for us though (tried both in java_arguments list and as lone applet parameter). The possible reason might be that the parameter should be used only with Webstart application (although it is not written specifically in specs).
While establishing Websockets connection, the connection stack trace is as follows:
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:790) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:787) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534)
at
sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1431)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1429)
at java.security.AccessController.doPrivileged(Native Method) at
java.security.AccessController.doPrivileged(AccessController.java:713)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1428)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
sun.plugin2.applet.SecurityManagerHelper.checkConnectHelper(Unknown
Source) at
sun.plugin2.applet.AWTAppletSecurityManager.checkConnect(Unknown
Source) at
sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:624)
So we looked at the latest publicly available source code of CrossDomainXML.java class (back from 2010 though). And from the code it is evident, that http connection is always used while retrieving crossdomain.xml file from server, regardless what is the original browser connection.
So the questions are:
Might it be a JDK bug or the strict usage of HTTP for crossdomain.xml is by design?
Is jnlp.altCrossDomainXMLFiles JVM parameter supported inside Sandbox applet?
Is there a way access the latest version of com.sun.deploy.net.CrossDomainXML.java source code to get a full picture of what is going on?
Thank you very much in advance.
Best regards,
Mark
in order to get rid of the http://myhost/crossdomain.xml request, there is nothing you can do except adding something like this into your java.policy file:
permission java.net.SocketPermission "myhost:1024-", "connect, resolve";
You can restrict that to a specific certificate signer in order to enforce this policy, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html#SocketPermission
We use it like this in an applet early in the init-process (applet constructor) and it works:
try
{
System.setProperty("jnlp.altCrossDomainXMLFiles", //
"http://www.some-domain.de/crossdomain.xml" //
+ ",https://www.secure-domain.de:8443/crossdomain.xml" //
);
}
catch (Exception e)
{
e.printStackTrace();
}
I have connected my Eclipse and cloned the https://github.com/OpenNTF/SocialSDK.git
I have a Tomcat 7.0 server and the SBT properties file
I have added the following web projects to the server:
com.ibm.sbt.bootstrap211
com.ibm.sbt.sample.web
com.ibm.sbt.web
When I open de sample web (http://localhost:8080/sbt.sample.web/home.jsp)
I get the page, but selecting a environment does not result in any change.
Which means that the pages remain empty...
The question is: can someone point me to a document or youtube movie that explains al this (I already have the labs PDF) but I want to get started with the latest build.
There should also be a JavaScript and a Java link on the header of that page.
There is a issue with the layout by which these two item disappear if the window is too narrow... you might try enlarging the window more than the screen or just deep linking to the samples in
http://localhost:8080/sbt.sample.web/java.jsp
for some of the samples, especially those using oauth, you will need to use your real machine address and the https protocol on port 8443.
I have an applet running in jnlp. My single jar file is signed. I accept the permissions prompt each time the JNLP client is launched. I can obtain the BasicService but it still throws a url permission denied exception when I try to follow a URI:
file:///D:\temp\test.txt
The file is present on all the Windows client machines I've tried and there are no security issues with opening it.
The issue happens when using a 32 or 64-bit JRE on the client. The server is 32-bit but I would think this irrelevant. The only clue (or red-herring perhaps) is that I get no security exception when the client and server are on the same host. If I use a remote client then I get the exception.
Whilst I needed to include the jnlp.jar file to compile the code, I assume it is not needed on the client if run using Java WebStart.
What else might you need to know? What else should I try?
Later that day...
Now this may or may not be a bug, it may be something wrong with the parameters in my jnlp file but I suspect that I'm using the wrong approach. Just to reitterate I'm trying to open a file:// url.
Here is what I am now doing:
I assumed that the Desktop facilities were only available in a Desktop Application - not an applet. I was wrong (and the documentation is scant - even on this hallowed site the only reference tells me to use JNLP Services for an Applet and Desktop for an Application) - Wrong (thankfully)
So you can use Desktop (having first checked that Desktop.isDesktopSupported() of course) in an applet - as long as you are running through WebStart not embedded as an applet.
I would propose the following approach to anyone.
See if Desktop is supported and use that.
Desktop.getDesktop().open(file);
If not then see if you can get the Basic JNLP Service.
BasicService bs = (BasicService)ServiceManager.lookup("javax.jnlp.BasicService");
and if that is available the use it with boolean openedOK = bs.showDocument(url);
Finally resort to the applet API.
AppletContext context = applet.getAppletContext();
context.showDocument(url, targetFrame);