Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • October 15, 2013

LiveConnect changes in 7u45

Guest Author

Java 7 update 45 (October 2013) introduces a new warning to users of LiveConnect applications. LiveConnect is a technology for Rich Internet Applications that allows JavaScript on a web page to make calls into an RIA, allowing the two to work together and load content. RIAs that do not use LiveConnect are unaffected by this change.

What changed: Users are prompted to confirm a domain when it makes its first LiveConnect call.
How is this different: Previously, LiveConnect calls were allowed by default.

For the first LiveConnect call (per-site), the Java plugin will ask the user if they want to allow interactions from [this domain] to interact with the currently running RIA. This allows the user to confirm known sources (such as the hosting site) and block alternate sources, such as on-page advertising networks or browser plugins. Prompts will displayed when that a web page performs a LiveConnect call. Prompts about LiveConnect cannot be made beforehand because the caller does not exist.

The LiveConnect warning looks like this:
LiveConnect Dialog: Allow access to the following application from this web site?

Developers looking to avoid this warning within their applications may use the optional Caller-Allowable-Codebase attribute within their JAR file’s Manifest.  The Caller-Allowable-Codebase attribute provides a list of domains that can make LiveConnect calls in to the application. This is different than the optional Codebase attribute, which describes the domains from which JAR files may be loaded, although both use similar syntax.


Manifest-Version: 1.0
Created-By: 1.7.0_45

Caller-Allowable-Codebase: example.com *.example.net

RIA developers looking to understand which messages will appear as a result of the end-user’s security slider may consult the Rich Internet Deployment Process flowchart. This chart depicts the checks that will be performed on a user’s system, from version-update checks through checking the signature and appropriate Manifest Permissions. The checks are split into two categories: Before your RIA and With your RIA.

Before your RIA:

  1. Is Java registered in the browser?
  2. Does a rule exist on the user’s system to whitelist this RIA? (e.g. a Deployment Rule Set)
  3. Is the user’s Java version at or above the security baseline?

With your RIA:

  1. Does the RIA have a valid code signature?
  2. Does the RIA meet requirements of the user’s security slider?
  3. Are LiveConnect calls from [this domain] allowed?

Join the discussion

Comments ( 55 )
  • guest Tuesday, October 15, 2013

    Adding "Caller-Allowable-Codebase: *" to the JAR's manifest file isn't making the error go away. Any ideas?

  • guest Wednesday, October 16, 2013

    Ditto. I have tried various combinations of URIs and cannot get rid of the security warning.

  • guest Wednesday, October 16, 2013

    Same problem for us.

    Caller-Allowable-Codebase seems have not any effect

  • guest Wednesday, October 16, 2013

    Tried multiple variants, adding Caller-Allowable-Codebase to manifest file with sites does not suppress the warning.

  • guest Wednesday, October 16, 2013

    Same problem here, I have added all the manifest entries, tried different combinations for Caller-Allowable-Codebase, but still no luck.

  • Pieter Wednesday, October 16, 2013

    Area: Deployment/Plugin

    Synopsis: Caller-Allowable-Codebase may be ignored when used with Trusted-Library.

    If a trusted, signed jar is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.

    This works, but now earlier versions causes as security concern to popup.

  • jf Wednesday, October 16, 2013

    Hi, I used following syntax, a nothing changed:

    Manifest-Version: 1.0

    Trusted-Library: true

    Application-Library-Allowable-Codebase: *

    Application-Name: applet name

    Permissions: all-permissions

    Caller-Allowable-Codebase: *

    Codebase: *

    Is there any reliable idea how to solve this issue?


  • guest Wednesday, October 16, 2013

    There appears to be a bug in the current implementation (7u45) - it conflicts with the Truster-Library attribute:


  • guest Wednesday, October 16, 2013

    Oracle writes:

    If a trusted, signed jar is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.

  • guest Wednesday, October 16, 2013

    For those developers like us who were blindsided by this change, and now have end users across the world getting horrible security warnings with our software, and from what I am reading, the proposed fixes are not working for people, how can we get advanced warning of Oracle breaking our software?

  • guest Wednesday, October 16, 2013

    If an end user declines the security warning (as many of our end users have already), what do they need to do to undo this so they can actually use our application?

  • guest Wednesday, October 16, 2013

    It seems that Caller-Allowable-Codebase doesn't work if Trusted-Library is present.

    see http://stackoverflow.com/questions/19393826/java-applet-manifest-allow-all-caller-allowable-codebase

  • guest Wednesday, October 16, 2013

    It seems that Caller-Allowable-Codebase doesn't work if Trusted-Library is present.

    see http://stackoverflow.com/questions/19393826/java-applet-manifest-allow-all-caller-allowable-codebase

  • guest Wednesday, October 16, 2013

    Yet another way to scare users off of using the Java plug-in. What is the rationale for this?

  • guest Wednesday, October 16, 2013

    Same problem with * wildcard

  • guest Wednesday, October 16, 2013

    Is there a way to tell Java that I trust a specific Java applet so I don't have to click this every day until the website I'm using updates the applet?

  • guest Wednesday, October 16, 2013

    Consider that removing " Trusted-Library " attribute will cause other warning regarding mixed code execution when using liveconect... So we can't consider it as a valid workaround.

  • guest Wednesday, October 16, 2013

    Has anyone else tried this solution regarding the Trusted-Library issue:


  • costlow Wednesday, October 16, 2013

    There's a set of options that System Administrators can do to whitelist applications on https://blogs.oracle.com/java-platform-group/entry/what_to_do_if_your -- please take a look at that while I look into the Trusted-Library post from Stack-Overflow.

    Specifying "Caller-Allowable-Codebase: *" is a bit wide because that would mean that JavaScript from any domain (including the ones described in the above news article) would be able to call in.

    Also a few points about the blog:

    * I have to click to approve comments, which I am doing.

    * There's a typepad integration for spam that's flagging a few posts. I think because a number of comments cited similar stackoverflow URLs within a short time on the same blog.

  • guest Wednesday, October 16, 2013

    I just want to point out (I'm the guy who asked above about how to trust an applet). The site we use (www.accuplacer.org) is external to us and not something we have control over (and not something we can stop using either). We can't fix the .jar by signing it ourselves since it's coming from Accuplacer's servers.

    I don't foresee them (Accuplacer) doing anything on their end anytime soon as their stance on things like that is that we should just stay on the previous version (they still only officially support Firefox 19 for example). So until they finally (if ever?) update the applet our students (I work for a college) are seeing this warning every single time they take a placement test. Many of them say "Don't Allow" because they're used to saying no to stuff like that at home. Even if we tell them ahead of time what to click.

    Previously, there was a "grant always" option that would pop the applet into trusted.certs and I could push that out to the other 49 computers so that students weren't prompted.

    For now, I have a program watching for the Security Warning window and it clicks "Allow" immediately. Not an ideal solution, but it seems to be a good workaround.

  • guest Thursday, October 17, 2013

    I have been using * for testing, not production, just to prove things work as expected.

    The workaround of removing Trusted-Library works for me. Is it being deprecated as it now seems redundant? What about users from update 21 who need the Trusted-Library attribute - forced upgrade? Better if update 46 went out ASAP that fixed this properly, however I can't find this issue listed in the bug database.

    I like the new changes but they're buggy/rushed and seems it's all too little to late (NPAPI being deprecated, etc).

  • tonyc Thursday, October 17, 2013

    It would be great if 745 could remember what site was allowed vs clicking allow all day long. Please..Pretty Please

  • costlow Thursday, October 17, 2013

    Within university computers or other areas with a known community, you can place a Deployment Rule Set on those machines to whitelist known applets. See https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets for the original post.

  • guest Thursday, October 17, 2013

    Removing the Trusted-Library manifest entry doesn't seem to work for us. When we attempt to load our applet with that entry removed, we get the following exception:

    java.lang.SecurityException: class "MyApplet" does not match trust level of other classes in the same package

  • Richard Maher Thursday, October 17, 2013

    Why was Caller-Allowable-Codebase Attribute not an applet <PARAM> like so many other plugin directors???

    We have a generic Applet that is used by any number of domains and pages and surely the most functionally appropriate (let alone sensible) place to throttle LiveConnect is at the <OBJECT> or <APPLET> stage?

  • rfmtm Thursday, October 17, 2013

    This is a real pain! At least let us users allow and save trusted sites and avoid this warning.

  • guest Thursday, October 17, 2013

    costlow wrote:

    "Specifying "Caller-Allowable-Codebase: *" is a bit wide because that would mean that JavaScript from any domain (including the ones described in the above news article) would be able to call in."

    For a commercial product that gets installed at the customer site, I don't see any other option than using '*' as the allowable codebase, since we don't know the domain where the product will be installed.

    Further, neither of the other options is really acceptable. Our customers cannot push out a Deployment Rule Set to desktops they don't control (eg, business partners that might run our product from the customer's site), and customers do not wish to re-sign our jars with their own certificate because it's not their product.

    Perhaps a useful setting for the "Caller-Allowable-Codebase" would have the meaning, "allow LiveConnect only if the domain of the script matches the domain of the jar".

  • Wolfgang R&ouml;ckelein Thursday, October 17, 2013

    I have an applet which uses the all-permissions model and I need to use liveconnect to call that applet from javascript, albeit the JS will always come from the same domain as where the applet jar resides, but the domain varies among our customers-

    What do I need?

    Prior to 7u45 I signed the applet and used Trusted-Library.

    http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html#newft reads as if I either sign the jar and use Caller-Allowable-Codebase or not sign and not use Caller-Allowable-Codebase?

    However the later seems not to work and for the former I need to omit Trusted-Library because of the 7u45 bug which will give problems in versions less 7u45...

    Any other ideas?

  • Wolfgang R&ouml;ckelein Friday, October 18, 2013

    'Perhaps a useful setting for the "Caller-Allowable-Codebase" would have the meaning, "allow LiveConnect only if the domain of the script matches the domain of the jar".'

    I would second this. I am in the same situation and the current possible settings are note satisfying.

  • guest Friday, October 18, 2013

    Please keep 'improving' the applet experience Oracle, each time you 'improve' things it makes it easier for me to justify removing applets from our solution. This 'fix' seems incredibly poorly thought out, badly/untested and yet another nail in the applet/webstart coffin.

  • guest Friday, October 18, 2013

    Oracle is really making it difficult for end users to run Java applets. The last couple of years have been a slow but steady death for applets.

  • guest Monday, October 21, 2013

    This issue and a number of others are making my organisation seriously question the value of providing our products to clients including java applets.

    There does not seem to have been a java 7 release that hasn't led to additional popups or dialogs that our end users need to respond to. These then significantly impact our clients perception of our product as they perceive these as being security faults in our software where the reality is that our software is no less secure than it was previously.

    Further worsening this is that our mostly non-technical client base doesn't understand the usual security alert which leads to further load on our already overworked support team.

    There needs to be a mechanism where organisations like mine can get early access to these releases so that we can forewarn customers of any issues or provide better solutions for them. As it stands we generally hear about these problems once clients are impacted which is far too late. I understand that this blog post and others like it is intended to address this but looking at the dates of the posts they are coming far too late for us to be able to proactively support our customers.

    So to summarise I have three recommendations:

    1. Provide early access to java releases in an easily downloadable format.

    2. Review security alerts and the text included in them for understandability from a typical non technical end users perspective.

    3. More carefully review the security changes being made with each release as to potential impact on third party developers and their products.

  • mkueng Tuesday, October 22, 2013

    I can only agree to the above statements that this fix is poorly thought through especially for applications that are deployed on customer infrastructures. The best would be to check if the javascript domain matches the jar domain and optionally another domain can be specified for special situations.

  • guest Tuesday, October 22, 2013

    It does not work for me, if I use the Caller-Allowable-Codebase and I have no Trusted-Library in the jar manifest. Also I have set the value for Caller-Allowable-Codebase to * , Still I get the Live Connect Issue. I cannot call a java method from the Java script

  • guest Tuesday, October 22, 2013

    I still have an issue, where the value for Caller-Allowable-Codebase is * and I am not using the Trusted-Library in the manifest file. I get the Live connect issue, when calling the java method from the javascript.

  • guest Tuesday, October 22, 2013

    The java script live connect only appears if other option than Later was pressed at the pop-up for installing new java release. It will force the users to install the new java otherwise no applet called by javascript will work.

  • SpiderWeb Tuesday, October 22, 2013

    How do I properly populate the



    fields in the new security warning prompt? Are they extracted from the manifest file, or from the certificate which is used to sign the JAR with? Can someone provide a link where these values are actually populated?

  • Deanna Tuesday, October 22, 2013

    Richard Maher: Allowing the caller to say "yes, I really am allowed to call this, honest guv'" would defeat the point of it.

    It's an option for the publisher of the applet to specify who can call it. Not the user.

  • Joshua Lyn Wednesday, October 23, 2013

    I can not use my applet any more after java 7u45 was released.

    I use java 7u25,

    this is the log from java console

    basic: Applet initialized

    basic: Starting applet

    basic: completed perf rollup

    basic: Applet made visible

    basic: Applet started

    basic: Told clients applet is started

    network: Created version ID:

    network: Created version ID:

    security: LiveConnect (JavaScript) blocked due to security settings.

    Please help me on this.I have signed all the jar ,

    Why it was blocked?I use the java u 25, why the log shows java 7u45.

    Is it possible to use javascript to java calling?


  • guest Wednesday, October 23, 2013

    I can only agree to the above statements - the script domain has to be matched against the applet domain automatically. Anything else is not acceptable for web applications with applets that are installed on customer infrastructures.

    The "Caller-Allowable-Codebase" is nice optional feature for special situations.

  • costlow Wednesday, October 23, 2013

    Wolfgans & Richard, I understand the comments above and acknowledge that "same domain" type matching would be convenient. The challenge with that is for applications which CAN whitelist the Caller-Allowable-Codebase because it guards against repurposing. An example would be a case where the application itself contains a vulnerability that isn't accessible on your own environment -- by moving the application and sending someone to it, your signature is unchanged but a new attack surface is exposed and same-domain is matched.

    Joshua, there's an explanation for what you're seeing with the solution on https://blogs.oracle.com/java-platform-group/entry/updated_security_baseline_7u45_impacts

  • costlow Wednesday, October 23, 2013

    A few people contacted me about getting emailed all comments versus approved non-spam ones to ask that this be fixed. I'm looking into doing that but in the mean-time I had to disable email notifications.

    While this is going on, I'll check to approve comments more often and turn them back on once I can.

  • Richard Maher Wednesday, October 23, 2013

    Deanna: It's not a matter of [Allowing the caller to say "yes, I really am allowed to call this, honest guv'"] it's allowing the authour of the document base to say "Hey, I'm including a whole lot of script files from other domains and I don't want them to be able to script this Applet". [would defeat the point of it] I'm not sure Oracle have articulated what "the point of it" is. Is it CopyRight Protection or marketing mechanism or is it a security mechanism? [It's an option for the publisher of the applet to specify who can call it.] You mean like they've always been able to do by interogating the results of Applet.getDocumentBase()?

    The whole idea of having to ship/package/manufacture a separate Applet for each customer is ludicrous!

    costlow: [because it guards against repurposing] Fine. *IF* the check scrutinized the domain of individual.JS files then I could see the sense in it, but my quick testing says it ONLY checks the Document Base. Please communicate exactly what you were trying to accomplish.

    On the subject of communication please feel free to assume a fair portion of responsibility for user-base feelings like this: -


    Cheers Richard Maher

    PS. Why don't I get any pop-up when I dynamically include an unsigned Applet at run-time with innerHTML="<OBJECT. . .".

  • costlow Wednesday, October 23, 2013

    Caller-Allowable-Codebase is about checking where JavaScript calls come from. Codebase is about the applet itself, though both are optional. I tried to point out the cause above in regards to on-page advertising networks with the news article, but some additional more technical research is at http://www.cio.wisc.edu/Shreeraj_Shah_DOM_Hacking.pdf or http://justinsomnia.org/2012/04/hotel-wifi-javascript-injection/ - nothing to do with copyright or marketing.

    Per the Mozilla bug, you can see Donald Smith on that thread at comment 68.

  • Richard Maher Thursday, October 24, 2013

    costlow: You're ability to listen seems to be suffering from the same impairment as Mozilla. Actually, they're busy rolling back their crime against the client-base whereas Oracle have just turned-down their hearing aids :-(

    [Caller-Allowable-Codebase is about checking where JavaScript calls come from.] Please explain what Oracle thinks determines where the JS is "from".

    1) The domain from the URL src that loaded the JavaScript

    2) The domain of the hosting page (Dosument Base)

    3) The domain of a page in the iFrame

    4) The domains of all the pages in a Frameset

    5) Which domain does EVAL() inherit

    Where is the documentation that answers these questions and helps developers arrive at deterministic outcomes?

    If everyone turns around AS THEY ARE and enters "Callable-Allowable-Codebase: *" what have you achieved apart from annoying a whole lot of people and forcing the signing of Applets that don't need it? You don't even mandate httpS for Pete's sake. What's the point of that?

    Will Oracle now demand a white-list of all domains with SQL coming into its Databases? All Apex clients must be white-listed?

    Please copy FireFox, step back from the abyss, and think this through.

    And finally, again, Why don't I get any pop-up when I dynamically include an unsigned Applet at run-time with innerHTML="<OBJECT. . ."? Be very aware that partial initialization init() IS taking place!

  • Richard Maher Thursday, October 24, 2013

    A couple of definitions from Javadocs to add to the Glossary after "from": -

    CodeBase: The base URL. This is the URL of the directory which contains this applet.

    DocumentBase: The URL of the document in which this applet is embedded.

    I have been using the terms deliberately and not interchangeably in my posts.

  • ColinB Thursday, October 24, 2013

    This feature really does look like a very poorly thought through fix.

    As another user stated, what about applications that are installed into a customer site where the domain is set by the customer.

    I would state the requirement is:

    "Allow the signed Java applet to interact only with Javascript which are served from the same server" - and optionally the server has to be in the intranet or trusted sites list

  • guest Tuesday, October 29, 2013

    This workaround doesn't seems to be the solution.

    I was trying to solve this problem with the Caller-Allowable-Codebase and no Trusted-library in the manifest (7.45 version), without success.

    I've already tried with the Deployment Rule Set configuration, to finally realize that the DeploymentRuleSet.jar needs to be trusted signed. And in first place, all this work did just because I can't have a trusted certificate.

    So, to summarize, I think the only way I can get rid of this (the several warnings, not just this one), is to have a trusted signed applet jar?

  • Richard Maher Wednesday, October 30, 2013

    What works for me is simply having the html and applet in the same domain. But then I don't get any pop-ups and activation simply fails silently otherwise. (Console log reveals error).

    Oracle seem to be pursuing a policy security through obscurity and only discussing this on a need-to-know basis :-(

  • costlow Thursday, October 31, 2013

    I'm not clear on how obscurity is a factor here. That term refers to things like "telnet is safe because I changed the port." These changes convert the parameters from a boolean "is untrusted code allowed, yes or no" to a matcher, "is untrusted code allowed, if so from where."

    Regarding the basis for communication, I've done several posts about this issue. For other planned changes, I have actually gone out to build tools and open source projects to either tell them or provided patches directly.

  • guest Wednesday, November 6, 2013

    I have tried various combinations of URIs and cannot get rid of the security warning. how to get rid of this warning in ma code what alterations are required

  • Peter Thursday, November 7, 2013

    Oracle Forms 11g is run in an applet(delivered in an Oracle signed jar) and supports a JavaScript API that allows JS calls to the applet code.

    How is Oracle going to deliver these Forms Jar files to clients to maintain the integrity of the applet using manifest attributes?

  • costlow Monday, November 11, 2013

    Peter, the Java group is intentionally separate from other Oracle product teams to avoid potential conflicts. We do talk to them but I am not able to provide answers for them. I suggest filing a support ticket or investigating Deployment Rule Sets to whitelist their applets without any changes.

  • Curious Monday, November 11, 2013

    Is there any way to add a trusted user with this feature on the client side? There doesn't seem to be a remember my response or a save this action button.

  • Brian D Tuesday, November 12, 2013


    Please have a look at forums.oracle.com/thread/2595634. According to JDK-8021826, my LiveConnect calls directly to the applet should be okay (even under Very High security) with a deployment rule set that covers just the applet with a certificate hash. However, it does not. A rule covering the codebase of the JavaScript calls directly is still required. I think this is a bug that needs to be reported with high priority.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.