Custom Protocol Handler not working in Chrome on SSL page

Question

I've successfully created and registered a custom protocol handler in my web application and it's working fine in all browsers. There's the initial warning dialog about launching an external application which is fine.

However when the app is deployed and the site is running under SSL, the custom protocol links no longer work in Chrome. I see the following message appears in the Developer Tools console:

[blocked] The page at https://my.site.com/path/to/page ran insecure content from iwd:-action=myaction

The same links work fine in Internet Explorer and Firefox.

Any ideas as to how to make this work? My external application by the way is a console application that's installed on the client.

edit: One extra important piece of information is that the link specifies a target which is a hidden iframe on the same page.

Solution 1

The solution was to not specify a target frame for Chrome users. It would appear that Chrome is looking at the url being passed from the main page to the embedded iframe and sees that the embedded iframe url is not secure and therefore rejecting it.

I don't think Chrome always behaved this way but with v30+ the solution appears to be to specify and empty target in the link.

Edit - expanded solution

Here's the JavaScript I use to clean the target attributes of the links (for Chrome users only) - Otherwise, the simple solution is to not specify a target attribute in the HTML in the first place.

// Get a list of all the links with external commands
var commandButtons = $("a[target='my_command']");
updateCommandButtonTargetsForChrome();

// Remove target attribute for Chrome only users
function updateCommandButtonTargetsForChrome() {
    var browserInfo = getBrowserInfo();
    if (browserInfo[0] == "Chrome")
        commandButtons.attr("target", "");
}

function getBrowserInfo() {
    var n = navigator.appName, ua = navigator.userAgent, tem;
    var m = ua.match(/(opera|chrome|safari|firefox|msie)\/?\s*(\.?\d+(\.\d+)*)/i);
    if (m && (tem = ua.match(/version\/([\.\d]+)/i)) != null) m[2] = tem[1];
    m = m ? [m[1], m[2]] : [n, navigator.appVersion, '-?'];
    return m;
}

Solution 2

It looks like the problem the whole time is how the url is written.

create the url without the "//":

customproto:xyzabcdef

Instead of:

customproto://xyzabcdef

Solution 3

Since it looks like all of the answers in this thread are already doing things specific to Chrome, there is a much simpler way to open an application via protocol handler that only will only work for Chrome.

Simply call window.location.assign("customprotocol://");. As far as the user is concerned, this will work exactly the same as the IFRAME approach used to. If the user does not have the protocol handler installed, nothing happens. If the protocol handler is installed, it will open the application.

This will only work in Chrome, as Firefox and IE will redirect the user to a "Could not load" page if they do not have the protocol handler installed on their machine.

Comments

[Ron Michael Zettlemoyer]

Glad to see I'm not the only one to run into this very same issue. Doesn't it seem like a bug in Chrome v30 though? Unless there is some way for a custom protocol handler to be designed as "secure" then this breaks anything that uses a custom protocol handler in an iframe of a secure page.

[Brian McGinity]

Can you elaborate as to how you did this? I am having the same problem.

[Catch22]

@BrianMcGinity I've edited the answer to provide the javascript code

[Brian McGinity]

I figured out 2083 is the documented max. Wonder if it possible for the executable to call a js function in the html page?

[Brian McGinity]

This is great!!!!! It works well. It fails in an iframe, so this fixes it: var w = (window.parent)?window.parent:window w.location.assign(service + '://' + data)

[Brian McGinity]

formating is off in my comment above: var w = (window.parent)?window.parent:window; w.location.assign(service + '://' + data)

[Brian McGinity]

I have referenced this thread at: stackoverflow.com/questions/2330545/…

[BenOfTomorrow]

There's an active bug in Chrome for this issue: code.google.com/p/chromium/issues/detail?id=318788