69b7f8704f00 I don't know if this helps you. I created an nginx rule to work-around the issue https://community.atlassian.com/t5/Confluence-questions/How-can-I-add-non-http-url-to-a-page-e-g-vscode-mailto/qaq-p/2939351#U2940814 

I'd like to use this to add  vscode links such as [vscode://settings/editor.wordSeparators] to make it easy for our developers to change the settings they need.

Seeing that a 18000 user company request this feature and it isn't solved ASAP gives me little hope. 

We also need that for my company (18000 users) for using with an internal tool that defines its own protocol.

We migrated thousands of pages with this from datacenter where is was working, and now people can't continue to edit their page the way they used to since 10 years.

This affects both new and legacy editor (which allows to add the link, but it <a href...> is lost when you publish the page.

https://getsupport.atlassian.com/browse/CES-62718

Dare i ask what's the progress on this if it was created in 2009?

We are in need of linking excel files and forcing them to open in the desktop app rather than the web view in SharePoint (using the "ms-excel" protocol. (e.g. "ms-excel:https://sharepoint.LinkToFile").

MS have done us all dirty and introduced "web view" for MS documents on SharePoint. Besides the fact it messes up word documents, our problem is, excel macros are inconsistent and we cannot reliably rely on the macros within in the web view.

However we still need to link the documents in our confluence documentation so staff know where to go / can access the files. I would rather not have to rely on peoples "good will" to not mess with the data in the sheets where the macros would normally prevent this (in desktop mode).

Now there's nothing stopping a user manually navigating to SharePoint and viewing it in web view there - but we could mitigate it to a degree if we could force the file to open in the excel protocol!

15 years in the making...

I ran into this problem using adt:// links. I actually don't understand why confluence should bother about the security or validity of links (apart from not loading their content automatically). If your browser's settings are broken, well, that's your problem, not confluence's  So why not just remove the restriction on the protocol and be done with it?

The on-prem version was capable of linking any protocol you liked, but the cloud version is not ... that feels like a big unnecessary step back when it comes to documenting your stuff.

Adding the possibility to allow custom links would be highly appreciated. It would save our users manual work by supporting using Confluence together with organization internal applications.

It could be a setting where we define a list of allowed protocols. In our case, it would be "fmp://".

Thank you.

We seriously need this ability as well. We deep link into our desktop apps and users can open areas of the app and try different things just by clicking a URL in documentation when custom schemes are supported

It's not really a security risk once certain schemes are excluded (like javascript), as the browser already handles alerting the user about the action from the URL and the user can allow/refuse/etc.

Also, the ability to disable opening a link in another page would be valuable, otherwise our users would keep getting empty pages when linking out to our apps

Deep links are a big deal these days on mobile and desktop - please ensure documentation can use them!

Please add this!

Using an external service such as TinyUrl is interesting but is a security risk and restricts our control over our own data. Setting up a custom service that does the same kinda defeats the idea behind having our Confluence instance in the Cloud. We really would like this restriction to be removed, too.