Confluence Atlassian Companion App Not Launching Applications

[Dalectric]

I've just updated my test server to 6.11.0 to try out the new Edit With feature.

I've installed the Companion app and it's running (Although due to my Windows user name having spaces in it, I had to update the registry Run entry so it runs correctly on startup by adding " around the path).

When I click Edit With ApplicationName (Where ApplicationName  could be Microsoft Word) I get the status pop up saying Editing with ApplicationName the image of the satellite dish and Opening file in ApplicationName but none of the applications open. I've tried it with PowerPoint, Word, Excel, PDF Reader, Visio and Notepad++.

Tested with Chrome, Firefox and IE11. I have an Apache reverse proxy if this could be a possible cause of the issue.

The log file for the app doesn't seem to provide much info either.

{"namespace":"adc:websocket","date":"2018-08-15T14:31:17.782Z","message":["new client connection"]},
{"namespace":"adc:websocket","date":"2018-08-15T14:31:17.868Z","message":["received message:","{\"type\":\"authentication\",\"payload\":{\"provider\":\"server\",\"payload\":{\"siteTitle\":\"Confluence Test Server\"}},\"requestID\":1}"]},
{"namespace":"adc:serverauth","date":"2018-08-15T14:31:17.871Z","message":["Found trusted domain in database:","con-testsrv"]},
{"namespace":"adc:websocket","date":"2018-08-15T14:31:17.955Z","message":["received message:","{\"type\":\"new-transaction\",\"payload\":{\"transactionType\":\"file\"},\"requestID\":2}"]},
{"namespace":"adc:websocket","date":"2018-08-15T14:31:17.968Z","message":["received message:","{\"transactionID\":\"c7225bc6-14e4-4469-aa81-e5427b4f2723\",\"type\":\"list-apps\",\"payload\":{\"extension\":\"txt\"},\"requestID\":3}"]},
{"namespace":"adc:websocket","date":"2018-08-15T14:31:17.969Z","message":["received transaction message for:","c7225bc6-14e4-4469-aa81-e5427b4f2723"]},
{"namespace":"adc:transaction:c7225bc6-14e4-4469-aa81-e5427b4f2723","date":"2018-08-15T14:31:17.969Z","message":["handling apps list request",{"extension":"txt"}]},
{"namespace":"adc:websocket","date":"2018-08-15T14:31:19.202Z","message":["received message:","{\"transactionID\":\"c7225bc6-14e4-4469-aa81-e5427b4f2723\",\"type\":\"launch-file-in-app\",\"payload\":{\"fileURL\":\"https://con-testsrv/download/attachments/84115459/JIRA%20Workflow%20Plugin%20Uses.txt?version=1&modificationDate=1534341166297&api=v2&download=true&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJqd3Quc3ViamVjdC5jb25mbHVlbmNlLXByZXZpZXdzLnRlbXBsaW5rc3Jlc291cmNlIiwicXNoIjoiNzg2YjFiZjY5MWJmYzkyYzFlMGM1ZTYwNjFjNmY0YTA3ODQzNjYyMTcxYzE4NWZhMWE3NWQxYTkxNGY2ZTBiZSIsImlzcyI6ImNvbS5hdGxhc3NpYW4uY29uZmx1ZW5jZS5wbHVnaW5zLnByZXZpZXdzIiwiZXhwIjoxNTM0MzQzNTM5LCJpYXQiOjE1MzQzNDM0NzksInVzZXJLZXkiOiIyYzkzOGFlNzRhM2ExN2M3MDE0YTNmMTdjNmUxMDAwMyJ9.ipuSWQm-iMT_bLFaDzeLXKrctQ-aR2ENOEsApVof60k\",\"applicationID\":\"32aaaeb002f68df42c78c02a5565fc0a\",\"fileName\":\"JIRA Workflow Plugin Uses.txt\",\"submitChangesURL\":\"\",\"autoUpload\":false},\"requestID\":4}"]},
{"namespace":"adc:websocket","date":"2018-08-15T14:31:19.202Z","message":["received transaction message for:","c7225bc6-14e4-4469-aa81-e5427b4f2723"]}
]
"namespace":"adc:transaction:c7225bc6-14e4-4469-aa81-e5427b4f2723","date":"2018-08-15T14:31:19.203Z","message":["handling file launch request",{"fileURL":"https://con-testsrv/download/attachments/84115459/JIRA%20Workflow%20Plugin%20Uses.txt?version=1&modificationDate=1534341166297&api=v2&download=true&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJqd3Quc3ViamVjdC5jb25mbHVlbmNlLXByZXZpZXdzLnRlbXBsaW5rc3Jlc291cmNlIiwicXNoIjoiNzg2YjFiZjY5MWJmYzkyYzFlMGM1ZTYwNjFjNmY0YTA3ODQzNjYyMTcxYzE4NWZhMWE3NWQxYTkxNGY2ZTBiZSIsImlzcyI6ImNvbS5hdGxhc3NpYW4uY29uZmx1ZW5jZS5wbHVnaW5zLnByZXZpZXdzIiwiZXhwIjoxNTM0MzQzNTM5LCJpYXQiOjE1MzQzNDM0NzksInVzZXJLZXkiOiIyYzkzOGFlNzRhM2ExN2M3MDE0YTNmMTdjNmUxMDAwMyJ9.ipuSWQm-iMT_bLFaDzeLXKrctQ-aR2ENOEsApVof60k","applicationID":"32aaaeb002f68df42c78c02a5565fc0a","fileName":"JIRA Workflow Plugin Uses.txt","submitChangesURL":"","autoUpload":false}]}
]

Any ideas?

[Dalectric · Accepted solution]

After working with Atlassian support I've fixed it for my test server by creating a new self-signed certificate and then using the following instructions to import it to the Trusted Root Certification Authorities Store on the client PC. The issue I appear to have had was my old self-signed certificate was out of date (it's only used internally for testing so I never bother updating it), and even if you import that to the client PC, because it was out of date, it still doesn't work.

The companion app could do with giving a bit more information about what's going on in this situation to help out end users. And it still makes me nervous that this will work with an official CA issued certificate, but I guess I'll have to create a setup to try that before I go live with the update to my production server.

[Dalectric]

I've also got this working with SSL without proxy. It's important that the CN field of a self-certified certificate matches the name of your server.

So if your server is at https://test-conf

Then the CN should be test-conf

[Savvas Sarikas]

We had the same issue with our test environment confluence instance using self signed certificate.
In our case an expired certificate was found in the trusted root certification authorities.
As soon as i removed the expired certificate and i imported the new one the confluence editing feature worked like a charm.

[Scott Dudley [Inactive]]

I have identical symptoms with Edit in App on IE11. One difference is that my Atlassian Companion debug log includes "undefined" at the beginning of the fileURL. For example:

"date":"2018-08-21T16:05:16.616Z","message":["handling file launch request",{"fileURL":"undefined/download/attachments/6324688/attachment1.txt [...]}

I dug through some of the Confluence-side server code to research this. The fileURL is populated through part of the Confluence file previewer code, and it is constructed as follows:

 var signedDownloadPath = document.location.origin
 + this._getContextPath()
 + tempFileContext.signedDownloadPath;

The problem is that, at least according to the Internets, IE11 only supports "window.location.origin" for sites outside of Compatibility Mode. Alternately, some other sites claim that IE11 doesn't support "window.location.origin"at all.

I played around with the zone settings in Internet Options to see if I could force 127.0.0.1 to be excluded from Compatibility Mode, but regardless of what changes I made, "window.location.origin" resolved to "undefined" in the F12 debugger tools console. If someone else has the time, it might be worth doing more tests here.

That having been written, I was actually able to get the app launching to work through some manual JavaScript manipulation that fills in the missing URL.

If I load the page, launch the previewer, and then execute the following code in the F12 developer tools JavaScript console, I can then click Edit in App and have it correctly launch the app (!):

window.location.origin = window.location.protocol + '//' + window.location.hostname + (window.location.port ? ':' + window.location.port: '')

Since you do not have an "undefined" in your debug log, this may not be the same problem as yours, but I am posting it in case it happens to work and/or helps out someone else.

[andrea schneider]

Hi Scott

The only entry we have in the companion.log is this line, which repeats every 5 minutes.

{"namespace":"adc:auto-updater","date":"2018-08-22T05:29:38.766Z","message":["checking for update"]}

But I see some errors in the Developer Console of iE, once I have clicked on Edit. These entries do never stop even when I close the overlaying Edit window.

Unhandled promise rejection Error: Failed to connect on any of the ADC ports
   "Unhandled promise rejection"
   {
      [functions]: ,
      __proto__: { },
      description: "Failed to connect on any of the ADC ports",
      message: "Failed to connect on any of the ADC ports",
      name: "Error",
      stack: "Error: Failed to connect on any of the ADC ports
   at Anonymous function (https://test.confluence.ourdomain.com/s/1381efaf7f22abc697287f272188f56c-CDN/en_GB/7801/0ac8ad8167063a2d16fb426a10b9044cf4bf1b17/6c79de73b14e26355b804c92a2bba44f/_/download/contextbatch/js/media-viewer,-_super,-viewcontent,-main,-page/batch.js?anonymous-access-enabled=true&confluence.table.resizable=true&highlightactions=true&is-server-instance=true&locale=en-GB:16329:29)
   at step (https://test.confluence.ourdomain.com/s/1381efaf7f22abc697287f272188f56c-CDN/en_GB/7801/0ac8ad8167063a2d16fb426a10b9044cf4bf1b17/6c79de73b14e26355b804c92a2bba44f/_/download/contextbatch/js/media-viewer,-_super,-viewcontent,-main,-page/batch.js?anonymous-access-enabled=true&confluence.table.resizable=true&highlightactions=true&is-server-instance=true&locale=en-GB:16122:13)
   at Anonymous function (https://test.confluence.ourdomain.com/s/1381efaf7f22abc697287f272188f56c-CDN/en_GB/7801/0ac8ad8167063a2d16fb426a10b9044cf4bf1b17/6c79de73b14e26355b804c92a2bba44f/_/download/contex"
   }

SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 403, Forbidden
SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 403, Forbidden
SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 403, Forbidden
SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 403, Forbidden

[Scott Dudley [Inactive]]

I've also seen the issue with "Failure to connect on any of the ADC ports issue", but only with Microsoft Edge and not IE.

In my case, the problem was that there was some Windows system setting preventing WebSocket loopback connections to the localhost. Toggling the appropriate setting under "about:flags" in Edge did not help at all, but the following command did the trick for me from PowerShell (and then restarting Edge):

CheckNetIsolation LoopbackExempt -a -n="microsoft.microsoftedge_8wekyb3d8bbwe"

I don't know if that is necessarily your problem since you're using IE, but I mention it just in case it helps.

[Jan-Peter Rusch]

Thanks!

Made my day.

JP

[Dalectric]

This seems to be related to using an Apache reverse proxy on the server. Disabling it made it work (In IE11) and enabling the proxy stopped it working again. More digging to be done.

Anyone else tried this with a reverse proxy?

[Dalectric]

More specifically it seems to be when using an SSL reverse proxy.

Disabling the SSL side of the proxy (Which also includes a change to the connector in server.xml) allow the app to be launched OK.

[andrea schneider]

Hi

We have similar problems but only with iE 11. Behind the proxy it doesn't even recognize that the Companion App has already been installed.

With direct access it works sometimes. But sometimes it doesn't notice when the file has been changed and saved in the external application.

On our server does it run properly with Firefox and Chrome.

[Dalectric]

Thanks for the reply.

I have some strange behaviour with IE11 when switching between SSL and non-SSL during testing. Clearing the cookies and history for IE with BleachBit and then restarting the PC seems to fix it for me.

I've tried it with Edge on a Windows 10 PC and that didn't recognise the app was installed at all...

So for your server the app works fine for Chrome and Firefox and you have an SSL reverse proxy?

[andrea schneider]

Hi

Yes we do have Airlock WAF in front of Cofluence. What might be special, I don't know if this make a difference, we're sending the requests over http to the backend server actually the Confluence pre installed Tomcat.

What I did test so far Chrome 68.0.3440.106 and Firefox 61.0.2 are working. Even though the hole thing looks not so user friendly to me, sometimes you save the changes in the file but the Companion App doesn't get notice of it. So I assume we're going to disable this function if it's somehow possible.

Our security is so strict we can't even clear our iE cache by ourselves... What happens when you're using a Private Session in iE? Does it change the behavior? On our system it does not, iE does never notice that the App is already installed.

[Dalectric]

Maybe it's something with how my Apache SSL is configured then.

Checked with IE11 using non-SSL Apache httpd and it works with both Normal and InPrivate browsing for me.

When it works it seems to pick up changes OK for me, but it sounds like you're having more problems in this area.

I've raised a support ticket with Atlassian to try and shed some light on the mechanism to see if I can figure out how to get it working. I'll keep this thread updated.

[andrea schneider]

Thanks for the information. I assume I have also to open a ticket. At least to know how it can be deactivated if it isn't going to work properly.

[Dalectric]

I think it would be a good idea to raise a request for your situation too. Especially if you need to have the ability to deactivate the feature.

[Dalectric]

This is also a problem for me using SSL to the Tomcat server with no Apache proxy.