Reference redactor removes links where it should probably restore them to the original input
If you include a reference in a link (using this supported but uncommon syntax) ...
[target](@All)... the link as a whole is removed if the target exists and you don't have permissions to view it. In this example, @All appears to be a valid, private namespace on GitLab.com. Render of the above Markdown:
target
Whereas if we try a different, non-existent target:
[target](@arcfqjrsheuokqjg)In other words, removal of the link signifies you have specified a valid target.
For reference, here's what it looks like when it works:
[target](@kivikakk)Note the styles and popover-on-hover, like a regular @-mention.
This works with other reference types, too. For example, akhya/private-test is a private repository in my personal GitLab account. I've created a single issue in it, so only the work item IID 1 is valid:
* [target 1](akhya/private-test#1)
* [target 2](akhya/private-test#2)Render:
- target 1
- target 2
The first link is removed by the redaction process, while the second one never resolved and so is left as a relative link. You can discover the existence of the target repository, and enumerate work item IIDs. You can probably enumerate most objects on the system with this.
Per the behaviour of ReferenceRedactor with non-link input, we should instead restore the link so that it behaves identically to an invalid target — both of the above should appear as relative links (that don't work).
Discovered while fixing `@ all` is rendered to `@ All` (#415958 - closed).