A bug has been identified in how Discourse handles URIs in markdown content. The issue arises when using URIs that do not follow the scheme:// format, such as urn:records:test:3 or geo:36.95733984,-122.0172856.
TallTed initially reported the bug, showing that Discourse fails to properly handle URIs in various markdown formats. Falco confirmed that the issue is due to the allowed_href_schemes site setting only working with schemes that use the scheme:// format, and later acknowledged it as a bug (Falco).
maiki further investigated the issue, noting that the bug affects various URI schemes, including geo URIs, and proposed a potential solution by checking for different scheme formats (://, :/, and :). maiki also provided a use case for the bug, where adding xmpp to the allowed href schemes results in an incorrect mailto link.
boospy asked if there is a workaround for GEO URIs, but no solution has been provided yet.
Discourse doesn’t handle it properly, no matter what markdown is used.
Just paste it, like an HTTP URI, and Discourse completely ignores the fact that it’s a URI, as here: urn:records:test:3.
Wrap it in <>, as <urn:records:test:3>, and Discourse flips the last two segments, as here: urn:records:3:test. Right-click-copy, and you’ll get either urn:records or test:3, depending on exactly where your mouse cursor is. Left-click it, and nothing happens, because it’s not quite treated as a URI.
Put it in full link markup, i.e., [text over `urn:records:test:3`](urn:records:test:3), and Discourse drops the last segment from the right-click copyable – and again, not-live-clickable – URI, live here in text over urn:records:test:3, where a right-click-copy will get urn:records:test, or as with [`urn:records:test:3`](urn:records:test:3), live here in urn:records:test:3, where a right-click-copy will get urn:records:test or 3, depending on exactly where your mouse cursor is.
I’ve not done exhaustive testing of all valid URI constructs. urn:records:test:3 just happens to be a real-world local example.
From careful eyeballing, it seems there are only three patterns used:
://
:/
:
My brain is having difficulty tracking where this is happening in relation to writing markdown and converting to href, but I think we if can figure out how to check for those three formats, we should be good for any scheme added by the admin.
For secure messaging and calls connect with me over Snikket/XMPP at xmpp:maiki@chat.v2.talkgroup.xyz.
Produces (with xmpp added to allowed href schemes):
For secure messaging and calls connect with me over Snikket/XMPP at <a href="mailto:xmpp:maiki@chat.v2.talkgroup.xyz" dir="ltr">xmpp:maiki@chat.v2.talkgroup.xyz</a>.
The href="mailto:xmpp:maiki@chat.v2.talkgroup.xyz" is the issue in this case. Noting as a use case for this bug.
