custom protocol in links #3298
-
|
Hi, I'm creating links with page.insert_link() of kind fitz.LINK_URI. The links are of procolol http://..., but also obsidian://... or even a custom protocol ("lib: ...") of mine and am puzzled at pymupdf behaviour. For a well known protocol as http the link is inserted as expected, but for the other links of custom protocols link kind is saved in a way that a later call to get_links() returns a changed kind to fitz.LINK_LAUNCH and the link uri is not recoverable from the dictionary of the link (but qpdf to json says it is stored somewhere). Did I need to register protocols somewhere to save them as links of LINK_URI kind? I'm missing something? In short, I'd wish all links were treated the same, irregardless of protocol. It helps me to cross-ref PDFs via apps launched from the docs. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
When specifying link kind LINK_URI and filling whatever string in the value of key "uri" then the link is stored as When parsing the link however, then indeed we compare with a limited set of starting strings to assume a non-file destination. We probably should change this and assume a non-file link whenever the URI string contains a ":" and does not start with "file://". |
Beta Was this translation helpful? Give feedback.
-
That would solve my problem and I'd welcome that. There is some security implications to think about, as in people creating malicious pdfs with bad links that exploit custom protocol vulnerabilities (for instance CVE-2022-30190). I think the duty of stopping those is in the reader apps, not the writing ones. For instance sumatra-pdf has a sidecar config file with a white list of valid protocols to open. IMHO it's not pymupdf duty to police the links, but I wanted to be fair with the issue. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the rapid reaction and your assessment! I agree with you in every aspect you mention. |
Beta Was this translation helpful? Give feedback.
Thank you for the rapid reaction and your assessment!
I agree with you in every aspect you mention.
I will turn this post into an issue then and label it as "enhancement" to feed it in our queue of changes. The required change is probably minor, so I don't see a major problem now.