Discourse 在 markdown 内容中处理 URI 时存在错误

贡献 错误
1

urn:records:test:3 是一个有效的 RFC 3986 URI。

无论使用何种 Markdown 格式，Discourse 都无法正确处理它。

  • 直接像 HTTP URI 一样粘贴它，Discourse 会完全忽略它是一个 URI 的事实，如下所示：urn:records:test:3。

  • 用 < > 包裹它，如 <urn:records:test:3>，Discourse 会交换最后两段，如下所示：urn:records:3:test。右键复制时，根据鼠标光标确切位置的不同，你会得到 urn:records 或 test:3。左键点击则没有任何反应，因为它并未被完全视为 URI。

  • 使用完整的链接标记，即 [text over `urn:records:test:3`](urn:records:test:3)，Discourse 会从右键可复制的（同样也无法通过左键点击激活的）URI 中删除最后一段，如下所示：text over urn:records:test:3，右键复制会得到 urn:records:test；或者如 [`urn:records:test:3`](urn:records:test:3)，如下所示：urn:records:test:3，右键复制会根据鼠标光标确切位置的不同得到 urn:records:test 或 3。

我尚未对所有有效的 URI 结构进行详尽测试。urn:records:test:3 恰好是一个真实的本地示例。

3 个赞
2

确实，我们的 allowed_href_schemes 站点设置仅适用于使用 scheme:// 格式的协议。

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

4 个赞
3

我无法判断这是在确认一个 bug，还是在说“是的，这是预期行为”……

请澄清一下？

1 个赞
4

这确实是一个 bug。它是由我们的清理代码引起的，该代码仅识别以 scheme:// 格式开头的 href 方案。

5 个赞
5

我刚刚遇到了一个与 geo URI 相关的 bug，其格式类似于 geo:36.95733984,-122.0172856。

我注意到 tel URI 有一个特例：

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

虽然 IANA 有 Uniform Resource Identifier (URI) Schemes 的官方列表，但我还是用了 List of URI schemes - Wikipedia 来核对各种方案，因为那里包含了示例。我正在查看的是那个……嗯……方案名称的“后缀”，即 ://（这个该怎么称呼？“方案格式”？）。

通过仔细观察，似乎只使用了三种模式：

  • ://
  • :/
  • :

我的大脑有点难以追踪这与编写 Markdown 并转换为 href 的具体关联，但我想如果我们能弄清楚如何检查这三种格式，那么对于管理员添加的任何方案都应该没问题了。

至于如何按方案进行验证……我还没头绪……:thinking:

我为这些格式起的非正式代码名称：

  • : “观察模式”
  • :/ “怀疑模式”
  • :// “双重怀疑模式”
1 个赞
6

将以下内容粘贴到 Discourse 中：

如需安全消息和通话，请通过 Snikket/XMPP 与我联系：xmpp:maiki@chat.v2.talkgroup.xyz。

生成的结果（在已添加 xmpp 到 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>.

此问题在于 href="mailto:xmpp:maiki@chat.v2.talkgroup.xyz"。将其记录为与此缺陷相关的用例。:slight_smile:

2 个赞
7

这能成为 GEO URI 的一种变通方法吗？我不是开发者。