-
Suggestion
-
Resolution: Unresolved
-
None
-
2
-
6
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
The rich text editor does not support creating links that do not begin with "protocol://"
This prevents usage of the rich text editor to insert "javascript:" links. Understandably from a security angle this can be considered to be useful. However many users of Confluence have other macros such as the html macro enabled because the user base of our instance is trustworthy. For these cases, there should be a Confluence setting to enable the users to enter in links in any format using the rich text editor.
Right now my workaround is to use the html macro to insert these kinds of links. However this makes things more difficult to maintain as compared to using the rich text editor.
- incorporates
-
- Closed
- is duplicated by
-
CONFSERVER-24700 Starteam Links don't Work in Confluence
-
- Closed
-
- relates to
-
- Gathering Interest
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
When I try making a shortcut with key "foo" and expanded value "foo://" it complains "Shortcut expanded value in not a valid URL in Confluence 5.4.3. So the work around does not seem to work for me.
True support for custom protocol handlers would be very useful here. It's weird to even say "support" since support is provided by the OS and the web browser. The fix needed here is for Confluence to stop blocking the support that's being provided by the other parties.
If there were security concerns just have "custom protocol handler" support off by default. Or have a whitelist of allowed protocols which we can set.
Suppose we have a desktop application called CityViewer. We have 10,000+ cities in the product. We want to clickable links on your Confluence pages. Maybe a page with the top 100 cities, one with cities in Europe or Cities from A to Z. The URL's would be like cityviewer://paris.
Seems like a very simple and reasonable thing to do? Would be very nice if it worked!
Philip Winston
added a comment - - edited When I try making a shortcut with key "foo" and expanded value "foo://" it complains "Shortcut expanded value in not a valid URL in Confluence 5.4.3. So the work around does not seem to work for me.
True support for custom protocol handlers would be very useful here. It's weird to even say "support" since support is provided by the OS and the web browser. The fix needed here is for Confluence to stop blocking the support that's being provided by the other parties.
If there were security concerns just have "custom protocol handler" support off by default. Or have a whitelist of allowed protocols which we can set.
Suppose we have a desktop application called CityViewer. We have 10,000+ cities in the product. We want to clickable links on your Confluence pages. Maybe a page with the top 100 cities, one with cities in Europe or Cities from A to Z. The URL's would be like cityviewer://paris.
Seems like a very simple and reasonable thing to do? Would be very nice if it worked! As a work-around, I found that I can create a shortcut link with the non-http protocol.
i.e.
Shortcut link is "protocol://%s", alias is "@protocol"
So, I paste in my "protocol://" link, delete the first part of it, then type "@protocol" at the very end and it becomes a link in a Confluence page.
I've gone into gory detail here: https://answers.atlassian.com/questions/31829
Any progress on supporting more protocols? I'd hope this would be an easy fix?
I just encountered the problem while trying to link to our company's homebrew document management system.
It is using links with the scheme "edmdoc:", but such links are translated to <a rel="nofollow" target="_parent">MyDocument</a> by the RichText editor.
On the other hand a URI using "edmdoc://" is translated into a real link, but the document management system is complaining about the double slashes.