Java Site Exception - Add sites easily to allow them to run with Java 8

Java Site Exception list .... and the nightmare continues...

The people over there at Java have been making it increasingly difficult for end users to run java applets; all in the name of security... This is a nice PR campaign but simply a 100% nightmare for most end users in both home and cooperate environments.

With the release of Java 8 there are NO medium security settings anymore, so adjusting security to medium in the past allowed any unsigned applet to run. Now Java in their infinite wisdom has done away with medium security settings...WTF !

Java is just pushing people to develop in other applications such as the FREE HTML 5 for example, which is already in most modern browsers and there is no need for all these stupid helper applications like java, and flash.

Java site exception list - how it works in the new java. 

In order to get any site that has a Java applet to run with Java 8 installed locally, you MUST now add manually each and every site to the site exception list. This list in the control panel. It is under as shown below:

Control Panel - Programs - Java

Then inside the Java control panel as shown below:

Security Tab at the top - Edit site list

This is simply a pain in the ass to access and to have to go through all the time; really!

This list is stored, or should I say can be stored in two different locations.

IF you are not in a cooperate environment and HAVE NOT used Java's deployment solutions to specify a generic site exception list for all users, then this list will be in the following place:

C:\Users\&username%\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

This is providing that there is NO deployment solution files like explained below.

IF you are in a cooperate environment AND have a basic deployment solution implemented for a generic site list for example the file will reside here:

C:\Windows\Sun\Java\Deployment\exception.sites

IF both files are present AND you are using Java 8 from Java 7, then the site exception will live in that windows folder/file. In this situation where both files are present, the original site exception list in the user profile ( First path above ) will no longer work with new Java 8 installed. You must manually open the site.exception list in the user location with notepad and move them to the site.exception file in the windows system folder. ALL further entries will be made here. NOT the user profile.

Quick rule:

1) IF C:\Windows\Sun\Java\Deployment\ DOES NOT EXIST, then the exceptions will be here for Java 8: 
C:\Users\&username%\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

2) IF C:\Windows\Sun\Java\Deployment\exception.sites DOES exist, the new entries will be here

I put together a small application that will make all these decisions for you and use the correct path depending on your Java version, and IF a basic deployment solution was used on your PC.

IF you have multiple versions then the program will not work, as I cannot guarantee IF the correct site exception list will be used, therefore you must have Java 7 OR Java 8 installed, not both or other versions like 6 for example. Once again it will NOT work with multiple Java versions.

Below is a screenshot of the simple easy to use interface:

It literally reads the correct site exception list, presents you with the complete list, and allows you to add to it easily without going through a huge hassle of getting it added. All in a simple easy to use interface without digging through menus.

Note: that if you are not an admin on your machine and your site exception list is in:
C:\Windows\Sun\Java\Deployment\exception.sites
You might have to be an admin or adjust the file permissions for everyone or a specific user(s) to adjust.

I am providing a Download link here for your convenience.

Java Fix: Your security settings have blocked a local application from running

java applet blocked

To all those people that are frustrated with java constantly blocking your applet every time.

I have come up with a ingenious solution to preventing this from ever happening again.
You wont get blocked, but prompted if the applet is not signed.




I wrote a program that upon every log in to verify and or set the security setting to medium every single time.

Now, some people say that will allow unwanted applets to run. That is possible IF they are signed. If they are not signed you will still get a prompt to allow to run, as some cooperate environments simply wont spend the extra monetary resources to hire a developer to update their applets as the one i work at does not like to do. Below is a list of security settings:

As of Java 7 update 51.

• Very High: Most secure setting - Only Java applications identified by a non-expired certificate from a trusted authority will be allowed to run.
• High (minimum recommended): Java applications identified by a certificate from a trusted authority will be allowed to run.
• Medium - All Java applications will be allowed to run after presenting a security prompt.

Java Security Slider

You can of course add them to the java trusted sites, which is totally different from windows trusted sites, which is in my opinion is kinda a pain since now you have to enter them into a different location all over again. If you scroll to the bottom there is a script for this that will pull them from Internet Explorer Trusted sites and add them to java sites.

I am going to explain how this script works so everyone understands what it does. First off, I am only writing code for 64 bit architecture, as 32 bit is pretty much on the way out fast.

The Java security settings are located in a file called:

" deployment.properties "

This file is located in the following location:

" C:\Users\%username%\localLow\Sun\Java\Deployment\ "

In this file as shown below is showing the default settings when you initially install java or a new user logs onto a machine for the first time,

java deployment.properties

What we are actually looking at are the default security settings; or the lack of them shown here. The " high " setting as default will not show in this file as it is default. What will show are " medium " and " very high ".

The setting for the security settings is called:

" deployment.security.level=MEDIUM "

The setting will show MEDIUM if you adjust your java slider all the way down, or if you write to line 6 of this file, with that setting as shown below.

What my script does is the following:

1) A windows task is created to run the file at log on. More on that in a moment.
2) the script waits and verifies the existence of the " deployment.properties " file. It will then wait 9 addition seconds and will continue on. NOTE: If the file exists then it does not wait.
3) It reads this file line by line to check for the existence of :

" deployment.security.level=VERY HIGH " or if such a deployment security level line even exists.

4) IF either of those conditions are true then the following line will be written into the file at line position 6 ' " deployment.security.level=MEDIUM " ' as seen below.

Line 6 security settings default location

This then forces the slide to medium even if grayed out, thus setting the security to MEDIUM.

5) If the line:

" deployment.security.level=MEDIUM "

already exists, then the script terminates.

OK so that's all this script does. What makes it work is to create another script to import a windows task to run the script at each log on, and create the necessary folder structure and place the actual exe that does the re-writing of the file in said locations.

The Windows task is set to run for:

" Users "

No high level privileges are needed as the data being written is in the user profile.

The file that does this is located in:

"C:\ProgramData\Scripts\java\" called " JavaSettings.exe ".

It will run at every log on, and does what is stated in the above description to alter the java file. This is particularly good in a domain environment where it is acceptable to run java security setting at medium and new users could be logging onto machines and facing the blocked site error message thus generating a call to the local Help Desk and getting assistance to set the slider to medium to overcome this. One could just run this as a one time shot for single log on machines. I will post a link to that as well as the one that creates the task.

The script runs silently for the most part except upon initial install of the task and associated files. in which a brief cmd window appears for a split second, and you will see an icon in the system tray briefly as well.

Also, upon first log in as a new user after the script has been installed on the machine, I have noticed that it could take a few minutes for the script to completely run to change the file contents as the network i am working with as it is antiquated and there is a bit of GP bloat being pushed to machines. This might not be the case with most modern networks with lean and efficient GP.

Below are the links to the 64 bit version of this:

Installer that creates the task and creates the necessary configurations is called JavaTask.exe

Stand alone one time fix to be run on demand on a per logged on user basis to set the setting to MEDIUM called JavaSettings.exe

I also created a stand alone import script that will import IE trusted sites to java trusted sites without any duplicates called ImportTrusted.exe

You can feel free to click on the right pane and look at some of my other work as well.

October 26 2014 - IMPORTANT UPDATE:

THIS WILL NOT WORK IF YOU HAVE JAVA 8 AND A DEPLOYMENT SOLUTION IN PLACE. ALSO, JAVA 8 DOES NOT SUPPORT MEDIUM SECURITY SETTINGS ANYMORE. YOU MUST ADD EACH SITE INDIVIDUALLY TO THE SITE EXCEPTION LIST