Call URL Handler leads to crash in new Teams

[MatthiasAbele]

I have a problem with an application which we are developing.

This happens only in the new Teams Application.

Basically I need to start an external Program, which is registered in Windows with a specific URL Handler. It worked fine in the old version. The command I use is a simple:

window.open(`myOwnUrlHandler:${u8sSIPAddress}`, "_self");

The error I get is:

Refused to frame '' because it violates the following Content Security Policy directive: "frame-src blob: data: https: acrobat2018: ales: arcb: blocked: bookmark: ciscotel: cloudya: com.bt.cloudwork.app: com.rainbowoffice.app: com.ringcentral.vodafonebusiness.app: companyportal: deltapath-engage: devtools: jamfselfservice: mailto: maxuccall: microsoft-edge: ms-access: ms-actioncenter: ms-appx-web: ms-excel: ms-infopath: ms-powerpoint: ms-project: ms-publisher: ms-settings: ms-spd: ms-teams: ms-visio: ms-whiteboard-preview: ms-word: msteams: notes: odopen: officeathand: onenote: openapp: opentouch: pdf: rcapp: rctelus: sebs: sip: sips: softwarecenter: suknil: tel: unifyoffice: vscode-insiders: vscode: vsls: wazo: webex: webextel: x-apple.systempreferences:".

What has changed? Am I doing something wrong?

Thanks for any suggestion...

[#2]

Hello @MatthiasAbele - Thanks for raising your query.
Could you please share the exact link format that you are using to test window.open?

[#3]

@ChetanSharma-msftI call window.open like this:

window.open("test-url-handler:email address removed for privacy reasons", "_self");

test-url-handler is a valid url handler registered in windows. If I call "test-url-handler:email address removed for privacy reasons" from a browser it actually opens the registered application as desired.

Thanks

Matthias

[#4]

Hello @MatthiasAbele - Thanks for sharing the information.
This issue is because of violation of Content Security Policy in Teams.
So, we will confirm with engineering team and let you know the updates whether it is not supported or a bug.

[#5]

Hello @MatthiasAbele
we have got an update from our engineering team.
We've always had that CSP header in place for the Teams Web Client (T1 and T2.1); it's now also in effect for the New Teams Desktop Client (T2.1). This header is necessary to ensure the security. If you need to launch out to a native app via a custom protocol, you can use any one of these options:

1)Call window.open with target parameter set to "_blank" instead of "_self".
2)Use an anchor tag with target="_blank"
3)Call the https://learn.microsoft.com/en-us/javascript/api/@microsoft/teams-js/app?view=msteams-client-js-late... or https://learn.microsoft.com/en-us/javascript/api/@microsoft/teams-js/?view=msteams-client-js-latest#... SDK API

[#6]

Thanks,@vikram-MFST 

Very valuable information. For all 3 options you gave me, the link is now working fine, no crashes.

But:

1) tel:+0000000000 is working

2) test-url-handler:email_address is NOT working

on 1) the correcty registered handler for tel: is called

on 2) nothing happens. When I use the openLink call, the Promise is correctly fulfilled, no errors thrown, but no URL handler outside is called.

Any idea?

Thanks a lot :)

[#7]

Hello @MatthiasAbele - As you are not getting any error, we are not able to investigate it further.
Did you try with using an anchor tag with target="_blank" or other suggested ways?

[#8]

I tried with all suggested ways.
All of them do not throw any error anymore.

But it's not working. It looks like as if the new teams app is not passing non-standard url handlers to the operating system. So something standard as tel: is working, and the registered application is called, but not those we are using for our application (which are also correctly registered in windows and work if called from a browser).

With the old Teams everything is working as expected.

[#9]

Thanks for sharing the information.
We will check with engineering team if all custom handlers are supported in new Teams client and let you know the updates.

[#10]

Hello @MatthiasAbele
We’ve had an allow list in place for both T1 and T2.1 desktop clients for a while now. These lists are aligned so any protocols which worked in T1 should also work in T2.1. You can find the current allow list here:
export const allowedProtocols = [
'devtools:',
'ms-actioncenter:',
'ms-powerpoint:',
'ms-word:',
'ms-excel:',
'ms-visio:',
'ms-access:',
'ms-project:',
'ms-publisher:',
'ms-spd:',
'ms-infopath:',
'ms-settings:',
'ms-whiteboard-preview:',
'onenote:',
'tel:',
'sip:',
'mailto:',
'odopen:',
'vscode:',
'vscode-insiders:',
'vsls:',
'microsoft-edge:',
'msteams:',
'ms-teams:',
'https:',
'ciscotel:',
'bookmark:',
'webextel:',
'arcb:',
'acrobat2018:',
'notes:',
'rcapp:',
'x-apple.systempreferences:',
'blocked:',
'webex:',
'sebs:',
'softwarecenter:',
'deltapath-engage:',
'companyportal:',
'jamfselfservice:',
'suknil:',
'openapp:',
'rctelus:',
'com.ringcentral.vodafonebusiness.app:',
'com.rainbowoffice.app:',
'com.bt.cloudwork.app:',
'officeathand:',
'unifyoffice:',
'rcapp:',
'rctelus:',
'com.ringcentral.vodafonebusiness.app:',
'com.rainbowoffice.app:',
'com.bt.cloudwork.app:',
'officeathand:',
'unifyoffice:',
'cloudya:',
'maxuccall:',
'ales:',
'opentouch:',
'wazo:',
];