We're in 2022 and still no winscp-sftp:// or sftp:// because the vendor thinks they know better than the system owners.

Hi Steven Lancashire,

We won't ever be able to support all schemes, as some schemes provide security risks, which is the reason for this filtering in the first place.

This should be decided by the admin, not by the vendor.

Duplicate of CONF-14393?

Were any of the 3.5.x version affected by this issue?

Thanks, Steve. I'll add my comments to CONF-28103.

Steve Lancashire: is this a closed/dead issue? Clearly there are customers who need this restriction removed from Confluence, and Lamar's comment indicates the product does not honor valid URI scheme syntax. Does the user community have any leverage in this matter or do we need to look at other wiki engines?

I agree with Atte. We also would like to use itms-services links. In my opinion Confluence should support all valid URIs. Here's the link to the RFC for URI general syntax:

http://tools.ietf.org/html/rfc3986#section-3.1

"Scheme names consist of a sequence of characters beginning with a
letter and followed by any combination of letters, digits, plus
("+"), period ("."), or hyphen ("-")."

So this is still unresolved and needs to be opened.

Unfortunately Bill there still are some restrictions in the protocol.

We only allow alphabetic characters in the protocol, so since your protocol has a hyphen it will not pass our security filter.

While the bug shows it's fixed/resolved, links with the "itms-services" protocol are unrecognized in Confluence 4.x (we are at 4.3.7).

Am wondering if anyone else uses this non-standard protocol with links in Confluence 4.x.

We have two systems in use (ERP and DMS) that allow accessing their content via custom protocols (scheme part of URI). Linking to them is not possible in Confluence because Confluence strips the href out of the link.

What about a whitelist of custom protocols to allow linking to? Or, at least, inform the user that the link he inserted (in edit mode they work, the href is stripped while saving the page) is not valid?

We would really like to add links to custom protocols.

Reopening, resolved in error

I would also like to be able to create custom protocols/links. Currently we would need the "m-files" protocol to be added. I can do the workaround, but for future releases it would nice to make it a supported feature.

rchang
Any update on this issue seeing as Confluence 4.3 has been released...?

ok for Robert's workaround above, I think I have found the line I need to modify as:

<regexp name="offsiteURL"
            value="(\s)*(((ht|f)tp(s?)|file|smb|irc|news|nntp|feed|cvs|git|svn|mvn|ssh|itms|notes)://|mailto:)[\p{L}\p{N}/]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+&amp;;:\-_~,\?=/!\(\)]*(\s)*" />

Not too sure what I need to add in here to allow file and folder links to my network drives i.e.: //server_name/folder/folder or //server_name/folder/folder/spreadsheet.xlsx

Any ideas?

D

If you guys are considering adding extra protocols allowed by AntiSamy: tel, vnc:// and afp:// would be nice for us. Thanks !

Workaround:

• Find <confluence_install>/confluence/WEB-INF/lib/confluence-4.x.x.jar and extract the contents of this file somewhere
• Locate and edit com/atlassian/confluence/content/render/xhtml/antisamy-confluence-storage.xml
• Around line 54 or so there should be a regex matching file, smb, irc, etc. Add the desired protocol to this list (e.g. 'hansoft') to this list and save
• Place the modified XML file in the following directory: <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/content/render/xhtml/ (create the directories if they do not exist)
• Restart Confluence

Please note that allowing Confluence to save/render more link types can be a potential security risk. Additionally, this workaround is not a supported operation and may not be applicable to future upgrades as the product changes.

Our instance on Confluence is internal only and all we want to be able to do is link to files and folders on our network drives. We are currently using Confluence 3.5.1 and this manages to provide this functionality without a problem. Links such as //network_drive/folder/file.doc and //network_drive/folder1/folder1_1/ work perfectly allowing us to write project pages and link out to all the relevant project documentation. I recently attempted to upgrade to Confluence 4.2 and this had the effect of de-rendering all of the links and displaying them as plain text. Needless to say the userbase were not happy at this and I have reverted back to 3.5.1.

Update: have just found the related https://jira.atlassian.com/browse/CONF-23575

Already filed a confluence support request against this issue (and was made aware that it is tracked here)

We use hansoft internally which uses a hansoft protocol/hook to open specific resources in our hansoft application. We relied heavily on linking to hansoft content in Confluence in 3.3 and our confluence wikis have thusly become crippled by the new link rendering behavior of confluence 4.2.

an example (heavily redacted) link would be

hansoft://redactedhansoftserver.ourdomain.com;Project$20Name/DocumentID/9999

Results of some quick testing I did with Confluence 3.5:

Wiki markup	Link renders?
[http://www.google.com]
[irc://irc.atlassian.com#confluence]
[xmpp:mryall@chat.atlassian.com]
[xmpp://mryall@chat.atlassian.com]
[trim://11/171915?edit&db=P1]
[javascript:alert('foo')]
[javascript://alert('foo')]
[data:image/gif;base64,R0lGODlh...0QAADs=]
!data:image/gif;base64,R0lGODlh...0QAADs=!

It turns out Confluence had its own ConfluenceLinkResolver, different to JIRA's, that hadn't used a hard-coded list of protocols since CONF-3086 was implemented for 2.0. As noted on that issue, we used to use UrlUtils.verifyHierachicalURI() to allow any kind of "hierarchical URI". I'm not across the full details of what that means exactly, but it appears to have allowed custom schemes.

However, in Confluence 4.0, a valid external link is now determined by matching a hard-coded regular expression in antisamy-confluence-storage.xml. This will currently match the types: http, https, ftp, ftps, file, smb, irc, news, nntp, feed, cvs, git, svn, mvn, ssh, itms, notes, mailto.

This needs some more internal discussion to decide how to proceed. I'm not sure how pluggable AntiSamy is, like we'd need to make this whitelist configurable or provide a setting to disable it. We could also attempt to recreate the behaviour of OSCore's UrlUtils.verifyHierachicalURI() in AntiSamy configuration, if we believe its checking is secure enough.

Luke - do you mean "trim://"? I don't believe a link starting with two forward slashes would ever have worked in Confluence – these are used for protocol-relative web links.

I'm investigating what the situation was in earlier versions of Confluence and whether we can make it work similarly now.

The reason that this isn't a clear-cut regression is because custom link types are a security risk as well as a useful feature. We need to protect against link types like 'javascript', and I'm not sure exactly what protection we had in place for this before and whether it has been intentionally made more strict for this reason.

We have a linking tool that creates URLs for our EDMS solution, TRIM. The tool creates links with the TRIM prefix. i.e (trim://11/171915?edit&db=P1)
This doesn't work in the latest version of confluence.

The "Advanced" tab in the Insert Link dialog should work for any link type that previously worked in wiki markup.

What specific type of URL are you trying to insert?