Upcoming Exception Site List in 7u51

Over the last year, many new security related features have been implemented. Many of those features have been related to browser plugins for applets and web start applications (RIAs). A number of end users and software vendors have asked for more ways to configure their environment and use of applications. 

The Exception Site List is a way for end-users to control their own application whitelist and continue using RIAs that could not be timely updated to follow previously announced security requirements. The Exception Site List provides a way to continue using a RIA but is not intended as a way to remove all warnings for the user. End-users will still see important prompts, but those prompts will no longer block.

Comparison to Deployment Rule Set

The introduction of the Exception Site List creates a second way for whitelisting RIAs and decreases requirements for system administrators.

 Exception Site List
Deployment Rule Set
 Introduced  Java 7 update 51 (January 2014)
Java 7 update 40 (September 2013)
 Intended for
 End-user System Administrator
 Formatted as
 Plain-text Signed JAR file
 If the two conflict with each-other
 Loses Wins

 For standard policy enforcement, some system administrators may lock down usage of the Exception Site List as they would with any other control panel setting.

Getting Early Access to the Exception Site List

Developers looking to test their applications in advance of 7u51 and use the Exception Site List can download early access of Java 7 update 60 over at the JDK 7 website. That website is the easiest way for developers to get early access of releases.

Adding a site to the Exception Site List

End-users can access the Exception Site List from the Java control panel.

  1. Use your browser to access the RIA that you normally use.
  2. Copy the URL from the address bar.
    Only choose directory paths ending in a / and not a filename.
    • Right: https://www.example.com/someApplication/
    • Wrong: https://www.example.com/someApplication/filename.html
  3. Open the Java control panel.
    • Windows/Mac - Open your system control panel or System Preferences and choose Java.
    • Linux/Solaris - Run the jcontrol command.
  4. Choose the Security tab.
  5. Click the "Manage Site List" button near the bottom.
  6. A new window will open.
    Screenshot of Exception Site List
  7. Click the Add button.
    Screenshot of adding an exception site
    • Right: https://www.example.com/someApplication/
    • Wrong: https://www.example.com/someApplication/filename.html
  8. Click OK. The window will close. You may see an additional prompt if you use an unencrypted protocol such as http or file. Choosing encrypted protocols defends against potential man-in-the-middle attacks.
  9. Back on the control panel, click OK to close it.
  10. Reload the web page on your browser to launch the RIA.

Files behind the Exception Site List

Update Jan 22: The Exception Site List is intended for end-users to create their own whitelist. If you are a System Administrator managing this across many machines, you will find the Deployment Rule Set much easier. Group Policy efforts are better used behind distributing a Deployment Rule Set. You can self-sign a DRS.

The Exception Site List is aimed towards end-users controlling their own Exception Site List.

The file controlling the Exception Site List is stored in the user’s deployment location as described in the deployment configuration. On my Windows 7 laptop, this location is C:\Users\ecostlow\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

The format is one site per line.

Sample customer support note

As changes are introduced, technical support representatives are usually asked for details. We will be creating a technical support note that can be downloaded and tweaked to help communicate this change to your customers. It is essentially a trimmed down version of this blog post with a stronger How-To message.

Update on Jan 14 2014: Here are the end-user instructions for using the Exception Site List. Otherwise if you need something more customizable, here is a sample Exception Site List support note. This is a docx file but it may appear as a zip.


When will there be an early relase version to test this new Exception Site List? We have many customers with older application versions and we will have to inform them before the official release of Java 7 Update 51.

Posted by guest on November 25, 2013 at 08:40 AM PST #

Halo. By referring your previous entry, it seems java 7u51 will block the java application in case we didnt do the fix accordingly. But, would you know any schedule regarding that?
Also, may i know is this blog hold by oracle officially? Can i assume all the information posted are true?

Posted by guest on December 04, 2013 at 11:54 PM PST #

For the first comment, there is an early access of Java 7 update 60 over at https://jdk7.java.net/ and I will update the post to point that out. 7u60 has the Exception Site List.

The second comment, 7u51 is planned for mid-January 2014 as described on http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Posted by costlow on December 05, 2013 at 12:30 PM PST #

I tried out the 7u60 version (Java-Plug-in to check if we are all set, but received "security: LiveConnect (JavaScript) blocked due to security settings.".
Same applet works fine with 7u45 and has a trusted signature and the Permissions and Caller-Allowable-Codebase attributes in the manifest. Another applet, with the same settings works but without LiveConnect calls, works fine.
Anything special missing for LiveConnect in 7u60?
The exception list and deployment rules would both work, but we should still be able to get the applet to run without it?

Posted by sdommel on December 09, 2013 at 12:37 AM PST #

I have tried 7U60. The exception list seems work for applet but not web start application without "href" link inside <jnlp>. Is this a bug with 7U60?

Posted by guest on December 10, 2013 at 10:31 AM PST #

Thanks. 7u60-ea has the Exception Site List feature but not yet everything it will have in the final release. There are tickets for sdommell and the JNLP/href issues; I will try to post the right links.

Posted by guest on December 10, 2013 at 03:39 PM PST #

Hi Guys,

I have the exact situation as sdommel, I even signed the JNLP with no use. I will test this on Java8ea b118 and see whether the problem appears there or not.

Posted by Kasimq on December 11, 2013 at 11:42 PM PST #

I also have the exact same problem as sdommel. A signed jar file where LiveConnect worked with 7u45 does not work with 7u60.

This is the manifest used for the 7u45 jar:

Caller-Allowable-Codebase: * https://*.<hostname>.com
Application-Library-Allowable-Codebase: *
Codebase: *
Application-Name: <Product Name>
Permissions: all-permissions

7u45 was a disaster for us. We also have to deliver different jar files for 7u21 through 7u40 because of the 7u45 changes. I hope we don't have to have a 3rd jar file.

Posted by guest on December 13, 2013 at 11:19 AM PST #

Can anyone at Oracle confirm the planned release schedule for the Java updates? I thought I had seen mention of an interim release scheduled for next week. But, we've seen nothing since then and have been suffering with each release in the last 12 months. So we are quite concerned we will be surprised again by some new 'feature' in the security side of the JVM. LiveConnect and the interplay with the Manifest bug in u45, for example.

If the CPU release u51 is the next scheduled release, it would be good to know that affirmatively. The current u60 is clearly a useless branch for testing as it doesn't behave like u45 and is broken in new ways.

Posted by Andrew Lippert on December 13, 2013 at 12:56 PM PST #

Early access candidates are intended for early access, especially when there is a release targeted in-between. The next planned release follows the pre-announced schedule at http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Posted by costlow on December 13, 2013 at 01:51 PM PST #

Same problem as other user mentioned previously. The signed applet with permission (all-permissions) and Caller-Allowable-Codebase (*) does not work in jre1.7u60(early release) but works fine in jre1.7u45.

Posted by SKL on December 15, 2013 at 07:16 PM PST #

Right, this is an early access build and not all changes have been put into it yet. While it's a reasonable way to examine the Exception Site List beforehand, it isn't complete, especially given that there is a release between now and 7u60.
Past comments have requested more information provided before releases, so I am pointing towards where to find early-access and explaining what's in it.

Posted by costlow on December 16, 2013 at 09:13 AM PST #

The Critical Patch Update Release schedule has been publicized, but there have been other releases that have directly impacted large swaths of our customer base. There was even a note somewhere that I can no longer find (I marked my calendar) that a release was scheduled tomorrow, December 17th - a non-Critical Patch release. Again, simple question: Is there any release scheduled before January 14th, 2014?

Posted by Andrew Lippert on December 16, 2013 at 05:27 PM PST #

I haven't posted anything that conflicts with that Critical Patch page and to my knowledge neither has anyone else. If you can locate a source stating otherwise, please share it and I will look into correcting it.
Communicating many things in advance, the next scheduled release is Java 7 update 51, whose date is on that page.

Posted by costlow on December 17, 2013 at 11:03 AM PST #

We are also experiencing the all to familiar error:
security: LiveConnect (JavaScript) blocked due to security settings.

We updated to 7U60 and used, among others, the following attributes in the manifest:
Permissions: all-permissions
Caller-Allowable-Codebase: *
Codebase: *

When using security level medium all works okay ...I take it that should not be the desired solution!

Will this problem be fixed on 14 January 2014?
Can we do anything to fix this issue?

FYI: The attributes used work perfectly on 7U45.

Posted by guest on December 23, 2013 at 01:44 AM PST #

Even though the Exception Site List is meant for individual users, could the list be stored in a common location so all users on a Windows system could use the same list?
As for the technical support documents, a section detailing how to deploy this file on Windows networks via Group Policy would lessen the support burden on many administrators.

Posted by baillard on December 24, 2013 at 10:32 AM PST #

I tried JRE 1.7u60 and I received an error saying 'Security Exception: attempted to open a sandboxed jar as trusted only'
The applet works fine in JRE 1.7u45.
My applet has :
Permissions: all-permissions
Codebase: *
Caller-Allowable-Codebase: *
Trusted-Only: true
within the manifest.
I was wondering if my applet would work with JRE 1.7u51.
Thanks in advance!

Posted by Gaurang on January 01, 2014 at 11:00 AM PST #

Baillard: Technically you could do that, yes. Or given that machines are already managed (by being subject to group policy), Deployment Rule Set might be easier and separate the role of ownership: The concern I would watch for is that users should still be able to control their own Exception Site List and if the files are locked...

Posted by costlow on January 02, 2014 at 10:04 AM PST #

I updated the java version to java 7 update 60 but when I used this link https://www.java.com/verify/ its showing Java 7 update 45 which was my previous version . Does somebody knows the reason behind it.

Posted by guest on January 07, 2014 at 03:45 AM PST #

I have an application that uses some 3rd party libraries. One of which requires the licence agreement to be in a a jar file under a META-INF folder.

All of the jars used by our application are signed with a Verisign Certificate and contain the following attributes in the manifest:
Application-Name: My App
Permissions: all-permissions
Codebase: *

Everything worked fine as of Java 7U45. I just tried our application with the Early Release of Java 7U60. When I launch the JNLP file, Web Start complains that the jar file containing the META-INF\licence.txt is unsigned.
When I use Java 7U60 jarsigner -verify myProblem.jar to verify that the jar is signed, it fails saying: "jar is unsigned. (signatures missing or not parsable)".

If I use the Java 7U45 jarsigner -verify myProblem.jar it says: "jar verified".

Any help would be appreciated.

Posted by MV on January 07, 2014 at 01:44 PM PST #

Will the Exception Site List entries persist after an update or will they be cleared out?

Posted by guest on January 08, 2014 at 07:36 AM PST #

Good question. The files for Exception Site List are stored outside any installation areas, so they'll persist across upgrades.

Posted by costlow on January 08, 2014 at 09:43 AM PST #


JRE 1.7u51 requires all the jar files to be signed. I have an applet that sends a request to an unsigned jar, but that jar file is never run, its just downloaded. I don't see any warnings for the unsigned jar file on JRE 1.7u45 saying it will be blocked (because the jar file is never run by JRE).

Will JRE 1.7u51
1. block unsigned jar files when it is about to run those? or
2. will it block unsigned jar files from downloading?
If it is case 1, my applet will work fine since the unsigned jar file is never run.
If its case 2, my applet will not work.

Kindly suggest the behavior in JRE 1.7u51.

Posted by Gaurang on January 08, 2014 at 10:10 AM PST #


Is there a way to disable the exception list feature (greyed button for example) ? I do not find a parameter managing this in the deployment.properties reference guide.

Thank you very much



Posted by Marin on January 09, 2014 at 06:46 AM PST #

Just thought I'd update this thread with a work around for the issue we encountered. We added a dummy file to the root level of the jar file that contained the license agreement in the META-INF folder, resigned it, and everything seemed to work with J7U60, J7U45 & J7U25. Hopefully it will work with J7U51 when it's released.

Posted by MV on January 09, 2014 at 08:23 AM PST #

Gaurang: If the JAR is just downloaded and used as an archive, that should be ok. The role of code signing is to give the end-user an understanding of whose application they're using. Generally speaking it's a good idea to sign all the JAR files that you distribute. If you have one that doesn't actually contain code and contains a license file or something else that uses JARs just as a package then you might be able to avoid it.

Marin: I'll check if there's a way to disable it. Using the feature is something that someone has to explicitly do within the control panel. The usual way that administrators lock settings is by managing a user's access to the control panel itself.

Posted by costlow on January 09, 2014 at 12:51 PM PST #


Thank very much costlow for invertigating. If not possible to lock/greying the site exception list button, it'll be useful to know how to "lock" the security tab in the java control panel itself (except by tweeking around with file system and/or rights) because I didn't find anything in deployment properties reference guide. Just in case it's needed : we are talking on windows 7

Thank you very much

Best regards to all

Posted by Marin on January 10, 2014 at 08:07 AM PST #

costlow: I've been looking unsuccessfully for the answer to Marin's question about how to disable the ESL via deployment.properties.

Thanks in advance,


Posted by Jerome on January 10, 2014 at 10:11 AM PST #

Marin & Jerome: There are a variety of ways to control end-user access to the control panel. I'm not a Windows admin so I don't know all the details. Under the "scaling distribution" section above, there is a link to the deployment properties documentation. The default value is posted above but you will be able to control which file is used through "deployment.user.security.exception.sites". You can certainly change that, but this feature is intended for users to explicitly whitelist something they need. If you manage their machines and control the policies then use your best judgment.

Posted by costlow on January 10, 2014 at 10:43 AM PST #

You are overzealously moderating this forum and depriving the developer community of critical I information. When will we get answers to the questions posted that you refuse to publish for all to see and learn from?

Posted by guest on January 10, 2014 at 08:25 PM PST #

I'm fine approving questions. The intent of these posts is to also have a comments section. For past entries it's not that I'm moderating them, the system is "open comments for ## days" and then they close.

Posted by costlow on January 11, 2014 at 06:43 PM PST #

I'll add a little more in terms of what to expect:
The Exception Site List is in part a way of mitigating some future impacts. Users can explicitly whitelist applications and sites. For example if you can't roll out an update per the RIA Checklist within a timeframe, clients can add you to their Exception Site List and run the app.
Tuesday's Critical Patch Update follows the release schedule posted above. The definition of the security baseline is the latest critical patch update, so that's going to go up as well and prompt end-users to update (details will go into the release notes).
The actual time that the release goes out isn't as helpful as it may seem. Client systems check in on the baseline periodically and that's the time that matters. If it helps, I'm in the Pacific time zone.

Posted by costlow on January 12, 2014 at 12:46 PM PST #


i'm trying to specify a central exception.sites file, but cant get it to work.
For example setting in deployment.properties:
Doesnt seem to work, monitored with procmon and noticed the value gets read, but is not properly handled, because it results in trying to read the exception file from:
C:\Program Files\Java\jre7\bin\file://srv/share etc

and putting the file in c:\program files\java\jre7\bin works just fine, but i would like to avoid it.
Any suggestions?

Posted by Szabolcs on January 15, 2014 at 05:58 AM PST #

can you add a wildcard i.e. http://*.mydomain.com/*/

Posted by guest on January 15, 2014 at 09:17 AM PST #

Szabolcs: Thanks for checking. Since you're on windows, have you tried using a mapped drive? The property value is a file destination but file:// is a protocol, which explains what you are seeing.

For wildcards, the match is depth-based. You could probably put the wildcard at the end but I would just leave that off.

Posted by costlow on January 15, 2014 at 10:15 AM PST #

I'm trying to add a site to the Exception Site List but there is an exclamation ! in red on the line to enter the name and even though I type in a url, it is not being added

Posted by guest on January 15, 2014 at 01:03 PM PST #

Is there a location that I can copy the exception site list to that will apply to all users on a computer rather than just one user at a time?

Posted by TheMTG on January 15, 2014 at 01:36 PM PST #

We also need to make an exception site list for all users.

Posted by jbennett on January 15, 2014 at 04:40 PM PST #

Is there a bug in exeption list? We have 9 exeptions that controlled with GPP. When user edit the list with his own Java Console, the count of exeptions cut to 7. First 2 of list cutted out.

Posted by guest on January 15, 2014 at 11:20 PM PST #

@costlow Hm, specifying local folder seem to work, is weord same syntax worked fine in deployment.config file for referencing a share on the network

Posted by Szabolcs on January 16, 2014 at 12:53 AM PST #

I installed the new Version. Is there a way to customize the Security level?"Low" or "Customize".
I want to customize the Security Level for "untrused Apps". I missing this one in the new Version.

Posted by guest on January 16, 2014 at 07:09 AM PST #

Constantly seeing errors on users machines "Program blocked by group Policy." Without disabling the Java Plugin and putting a burden on support for running UAC controls to bypass the error, what options do we have to prevent the error from occurring?

Posted by GP Error on January 16, 2014 at 08:31 AM PST #

I'm trying to add all printers and routers to the Deployment Rule Set, but looks like i'm required to add each IP to the ruleset.xml... is any way to add a ip/network (http://10.* or http://[]).

If its not possible, could the Exception Site List help me on this problem?

Posted by Daniel on January 16, 2014 at 09:37 AM PST #

worked great on my MacBook. Thanks.

Posted by guest on January 16, 2014 at 10:22 AM PST #

I'm still having to add my app to the exceptions list, though I seem to have done everything right.

My applet is composed of 4 jar files--the applet and three supporting jars it shares with other apps. Each jar was signed and timestamped 6 months ago with a certificate from GoDaddy. Each jar's META-INF/MANIFEST.MF includes "Permissions: all-permissions" and "Codebase: *" However I still get a Java alert that a self-signed (yes, though it's a GoDaddy cert) applet cannot be loaded. The applet will only load after I add application URL to the Exceptions Site List. (Java 1.7.0_51 in Firefox with MacOS 10.8.5)

What's missing?

Posted by Thad on January 16, 2014 at 11:18 AM PST #

Hi, my customers update to the new version yeturday, and now my file upload applet can't be loaded because it's auto-signed. It seems there is no-more way to add a trusted site in this version. I can't afford a commercial certificate, how can I proceed?

Thank's for your answers,

Fred B.

Posted by Fred on January 16, 2014 at 11:39 PM PST #

Do you have any ideas how we can distribute Exception Site List for more users? Is there a file which is describing this data?

Posted by guest on January 17, 2014 at 01:52 AM PST #

We were able to get exception sites list working, however there is no way to lock it down, by either blocking the Edit button or on the further dialog, locking down Add and Remove button. We need to deploy the settings via GPO but it is going to be less than perfect if users can edit the list.

On another note, the documentation is not quite correct in terms of string formatting for file paths. Trial and error shown that for local path you would have to use C\:\\folder\\folder\\file

Oracle, if you do not provide official support for JRE, please produce correct documentation at least.

Posted by Greg on January 17, 2014 at 04:28 AM PST #

Please update the FAQ at https://www.java.com/en/download/faq/exception_sitelist.xml
giving examples of wildcard usage (some blog entries here hint that they are supported). Also are there requirements for creating the exception.sites file from scratch, for example is the file format ANSI, UTF-8, Unicode? Is a blank line required at the end of the file, and do lines need to be terminated by CRLF?

Also if we encounter a large site that has these Java warnings, can we report them to Oracle so it can be added to the list on this help article http://www.java.com/en/download/help/java_blocked.xml

Lastly, if your webmaster can edit the MIME types on https://blogs.oracle.com the SampleSupportNote_7u51ExceptionSiteList.docx should be able to be specified as a download.

Posted by baillard on January 17, 2014 at 08:29 AM PST #

We're getting a number of comments here and I'm working to approve and address things as I can. I've left out a few only because the scrolling is getting a little long.

On distributing exception site lists: This is really intended for the end-user. You technically can roll it out like anything else, but if you're a network admin then you probably want to use Deployment Rule Set. Here is what Facebook does: https://www.facebook.com/notes/protect-the-graph/protecting-the-java-browser-plugin/1405538516352962
If you need this on machines where you don't have policy control, it's probably easier to update your app or link people to the java.com article.

Fred: You can do self-signed, but the certificate needs to be trusted through a separate step. See https://blogs.oracle.com/java-platform-group/entry/self_signed_certificates_for_a

Baillard: The Java.com team has a list of some things that have been identified. Use the contact links there to report something. Even though we got word out there by updating a few open-source projects and using stackoverflow, it's hard to reach everybody. The technical documentation for the Exception Site List is http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/exception_site_list.html

Posted by costlow on January 17, 2014 at 02:02 PM PST #

I have went to the Exception Cite List and listed two urls for Yahoo games and yet neither one will load. Why such a big deal to use java on any site? Looks like yahoo spades is over for me.

Posted by guest on January 17, 2014 at 03:24 PM PST #

The Security tab in the Java Control Panel applet only shows me the "Certificates" button. Is the "Manage Site List" button hidden or missing?

Posted by dwilson2 on January 18, 2014 at 02:30 PM PST #

I'm trying to add a site to the Exception Site List but there is an exclamation ! in red on the line to enter the name and even though I type in a url, it is not being added

Posted by guest on January 19, 2014 at 07:10 AM PST #

I am attempting to set the java exception list after the update, but the stupid Java Control Panel will not run the latest version I have installed. I have Version 1.7.51 installed, but the Control Panel is still using 1.7.45. I have tried going to the Java tab -> View, and adding the new version while disabling the old. I can do that for the User tab, for the System tab does not allow me to add any new ones. I have tried restarting the computer after the update, but nothing changed. And I tried changing the JAVA_HOME system variable, but the old version is STILL being used instead.
Java's website version checker says I'm using the new version.
I need a solution NOW. I have to create a tutorial page on my website to explain to my users why they can no longer run my app and how to add my website their exception list, and I can't do that if I can't even get my own environment to work properly...

Posted by guest on January 19, 2014 at 10:58 AM PST #

If you don't see the Exception Site List in the control panel, check for old versions. It's possible to have different Java versions on a computer at the same time (usually for compatibility). The easiest way is to uninstall the old version, otherwise you can manage them on the Java tab of the Java control panel.

For adding sites, make sure you click the "Add" button before OK.

Also if you have a number of users who need to use an applet that's hosted on your website, it's probably easiest to update it per the RIA checklist.

A different but interesting note for server-syadmins is that OpenBSD is also moving towards signed packages: http://marc.info/?l=openbsd-misc&m=138992613426488&w=2

Posted by costlow on January 19, 2014 at 04:00 PM PST #

I was the guest user who posted yesterday.
I managed to locate the configurations for the Java 7 Update 51, but it is not the default Java Control Panel which I access through the Windows Control Panel (I had to look through the file system to locate the new one). No idea why; I am working with people on another forum to try to fix the issue.
I intend on getting rid of the older versions after properly ensuring my projects operate correctly after updating the JDK in my IDE.
I have followed the RIA checklist, but purchasing a signature from a CA is not an viable option for me, so self-signatures are the best I can do. I know that makes my product seem "less safe", but I suppose that is left up to my users to decide if they trust me. I'm certainly not doing anything unethical. I have explained the situation to my users and advised them how to add my site to their exception list. If they trust me, they know how they can continue to use the program, if not, well I guess I'll lose some users.

Posted by guest on January 20, 2014 at 05:58 AM PST #

We are deploying Java with a local 'deployment.config' and centrally stored 'deployment.properties' and 'exception.sites' and that much works.

But same as [Daniel], we need to specify whole address ranges in 'exception.sites' for java-based hardware management (printers, switches, etc.). Specifying a wildcard in the IP-Range doesn't seem to work, though.

Any hints on how to do it?

Posted by guest on January 22, 2014 at 07:17 AM PST #

We are deploying Java with a local 'deployment.config' and centrally stored 'deployment.properties' and 'exception.sites' and that much works.

But same as [Daniel], we need to specify whole address ranges in 'exception.sites' for java-based hardware management (printers, switches, etc.). Specifying a wildcard in the IP-Range doesn't seem to work, though.

Any hints on how to do it?

Posted by PCP69 on January 22, 2014 at 07:47 AM PST #

Perhaps I was not clear above. If you are an administrator managing systems for others, you should use a Deployment Rule Set. The Exception Site List is intended for end-users who can copy+paste URLs but don't know what a /8 is. Exception Site List does not do wildcards, DRS does.

Posted by costlow on January 22, 2014 at 10:38 AM PST #

Thank you to Greg and Szabolcs for their comments. As Greg mentioned in his post the documentation for deploying a system wide Exception Site list is not accurate. I wanted to provide what I was able to do to get this to work.

System wide configurations can be made using the Deployment Configuration Properties. One of the 3 files that must be hand made in order to deploy the Exception Site List. Below are the steps I used to get this to work, I hope this helps others.

1. Create 3 new files and store them in C:\Windows\Sun\Java\Deployment. You'll need to create this directory path.
1a. deployment.config
1b. deployment.properties
1c. exception.sites
2. The deployment.config file should look like this:
3. The deployment.properties file should look like this:
4. The exception.sites file should contain the URL(s) of sites you would like added to the Exception Site list. One URL per line, and should end with a / character.

Once all 3 files are created and placed in the correct directory, the Java 51 console will use these settings to Set the Security Level to High and populate the Exception Sites list. Both of these setting will also be locked from being edited by a user with the Java console.

I used the comments in this post and these two links to get this working.

Posted by guest on January 22, 2014 at 12:25 PM PST #

Post a Comment:
Comments are closed for this entry.

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.


« November 2015