Custom URL scheme always has a unsafe: prefix

[MBulli]

We use our own inhouse developed CRM system. The contact lookup integration works great but we have encountered a problem with CRM linking.

Our application uses an application specific URL scheme for deep linking into our software. Let’s say a valid URL for our software is 'test:key=[ContactID]'. Thus, I set the contact URL prefix to 'test:key=' and the suffix empty in the CRM options page (we use the 'Database MsSQL' template, no custom xml template). As the contact lookup works, a valid ID is found and a valid URL is generated in the dialer. However, the link does not open our software. Fortunately, one can copy the CRM link in the dialer and the URL is copied to clipboard. In our example the copied URL is: 'unsafe:test:key=4242'.

So, for some reason a 'unsafe:' prefix is added to the otherwise correct URL. A quick search led me to this stackoverflow post referencing to this one. It seems that the 'unsafe:' prefix is a feature of AngularJS which marks any not known protocol as unsafe by appending the prefix. I don’t know if the webclient is actually written with AngularJS, so the prefix might have another reason.

Is this intended behavior?
Right now, I don’t know how to workaround this behavior. Using http is not an option for us, as our software is not web based. We could register our software to the 'unsafe:' scheme as a temporary hack, but in the long-term it would be nice if the webclient could generate the URL without the 'unsafe:' prefix.

Our software is Windows only.
We have 3CX 18.0 Update 5 (Build 418) with a dedicated pro license.
Everyone uses the webclient installed as windows app i.e., not the old windows client.

Any help is appreciated

 

[edossantos]

Indeed the Web Client is written in AngularJS, so that's the cause of the "unsafe:" prefix.

The hack mentioned in that Stack Overflow page requires that we edit the Web Client code to add your protocol as a know protocol. As you will understand, we can't do this, because the Web Client can't be tailored for a specific company.... Unfortunately I don't see a solution for this, apart from registering your custom protocol with the "unsafe:" prefix in your user's machines.

 

[MBulli]

Yeah, I understand that you can't hardcode our protocol in the web client or allow every protocol. But there are two possible ways to do this in theory:
- Add an option in the integration mask or in the parameters which allow to define my known protocol.
- Or, more automatic, parse the CRM link URL, get the protocol part from it and send it to the web client.

Of course I don't know anything about your software architecture so I don't know if it is feasible but surely possible.

We actually found another better workaround:
A http CRM link points to a PHP script which receives the CRM ID and triggers a redirect to our URL with the right protocol.
Luckily, most browsers will close the freshly opened tab immediately after the redirect.

So it seems to work for us in practice that way. But in my opinion this is something the web client should support at some point even if it's a special case for sure.

 

[edossantos]

Yeah, I understand that you can't hardcode our protocol in the web client or allow every protocol. But there are two possible ways to do this in theory:
- Add an option in the integration mask or in the parameters which allow to define my known protocol.
- Or, more automatic, parse the CRM link URL, get the protocol part from it and send it to the web client.

Of course I don't know anything about your software architecture so I don't know if it is feasible but surely possible.

We actually found another better workaround:
A http CRM link points to a PHP script which receives the CRM ID and triggers a redirect to our URL with the right protocol.
Luckily, most browsers will close the freshly opened tab immediately after the redirect.

So it seems to work for us in practice that way. But in my opinion this is something the web client should support at some point even if it's a special case for sure.

Good that you have a working solution.

Letting you configure this is not an option, because that needs to be in the source code, before the app is built.