[Bug]: Expose an API to overwrite the default link validation

[rfgamaral]

Affected Packages

extension-link

Version(s)

2.6.6

Bug Description

We've finally integrated the latest Tiptap version with our product, and unfortunately this and this caused some issues for us.

We've started getting loads of support tickets of people complaining that custom links copied from the most various apps could no longer be used to link text in the editor. To give a few examples, apps such as Airmail, Bear, Obsidian, give you links with custom protocols (i.e. airmail://, bear://, obsidian://), and these stopped working. As you can imagine, figuring out a list of all supported custom protocols for all the apps out there will be nearly impossible.

To work around this issue (it was really starting to get critical), we had to put up a patch to remove link validation, but we would love to have a more clean implementation, and remove the patch as soon as possible.

Expected Behavior

I think the best option is to keep the default behaviour as-is, but somehow allow the extension to be configured (or extended) in a way that allows to completely customize/overwrite the link validation behaviour in the most clean possible way.

Additional Context (Optional)

But I do think that the default behavior is quite valid & safe for a web-based editor that isn't really going to deal with custom protocols as much, but I of course understand your concern & it should be accounted for.

(by @nperez0111 - source)

I agree that the default behaviour is valid and safe for a web-based editor, but for more advanced and/or different usages, it would be useful to be able to customize the behaviour for different needs.

---

As an aside, I think there's a bit of a disconnect between the default allowedProtocols list, and the registerCustomProtocol function. For instance, you are allowed to have links with the tel, callto, sms, cid, and xmpp protocols, but these are not auto-linked, because they are not registered as custom protocols (the other ones seem to be accepted by linkify.js by default, despite not being directly registered either). Something to consider when reviewing/refactoring the implementation.

Dependency Updates

• Yes, I've updated all my dependencies.

[rfgamaral]

@nperez0111 If I work on a PR for this, that gives the option to the consumer to have full control on link validation while having the default link validation as-is, would that be something that you be willing to accept? Or do you think this needs a different solution?

[nperez0111]

Hey @rfgamaral I appreciate you offering your help with this. I've had this on my back burner for a few weeks now and have not had the time to look more into it.

I think that would be the perfect solution here, I don't know exactly how I'd implement it but as long as you could keep back-compat of doing the safest possible thing, I'd be willing to take something that could configure it.

Which right now our best solution thus far has been a whitelist which I like for simplicity, but if you can figure something else out that would be great too.

I very much appreciate you offering to help on this, and look forward to your PR!

[SanderLeenders]

Hey,

is there any progress on this? We are also experiencing issues with the renewed isAllowedUri. It prohibits the use of relative paths.
A solutions for us would be an optional custom uri validation with a fallback to the current isAllowUri

[SanderLeenders]

@rfgamaral does this meet your expectations?

[nperez0111]

Released with 2.10.0