Bug(s) in Discourse handing of URIs in markdown content

Contribute Bug

AI-generated summary

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.

1

urn:records:test:3 is a valid RFC 3986 URI.

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.

3 Likes
2

Indeed, our allowed_href_schemes site setting only works with schemes that use the scheme:// format.

https://github.com/discourse/discourse/blob/master/app/assets/javascripts/pretty-text/addon/sanitizer.js#L59

4 Likes
3

I can’t tell whether that’s acknowledging a bug, or saying “yes, that’s the expected behavior”…

Please clarify?

1 Like
4

That is indeed a bug. It’s caused by our sanitizer code that only recognizes href schemes that start with the scheme:// format.

5 Likes
5

I’ve just run into this bug with geo URI, which look like geo:36.95733984,-122.0172856.

I see there is an exception for tel URI:

    if (allowedHrefSchemes.includes("tel")) {
      extraHrefMatchers.push(new RegExp("^tel://\\+?[\\w\\.\\-]+", "i"));

There is Uniform Resource Identifier (URI) Schemes, but I used List of URI schemes - Wikipedia to check the schemes as they include examples. I’m look at the, um, scheme-name “suffix”, the :// (what is that called? “Scheme format”?).

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.

No idea on how to validate per scheme… :thinking:

My unofficial code names for the formats:

  • : “observing”
  • :/ “skeptical”
  • :// - “double skeptical”
1 Like
6

Copying and pasting the following into Discourse:

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. :slight_smile:

2 Likes
7

Can this somehow an workaround for GEO URI’s? Am not a dev.