Summary: | Hyperlinks with Basic Auth (https://user:password@example.com/) get lost in PDF export | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | PirMei <myspampirm> |
Component: | Printing and PDF export | Assignee: | Dave Gilbert <freedesktop> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | himajin100000, ilmari.lauhakangas, ming.v.hua, myspampirm, sberg.fun |
Priority: | medium | ||
Version: | 7.0.6.2 release | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=146496 | ||
Whiteboard: | target:7.4.0 target:7.3.3 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 103378, 107733 | ||
Attachments: |
LibreOffice Draw Document containing a hyperlink with HTTP basic auth credentials
PDF generated from LibreOffice Draw document containing a hyperlink with HTTP basic auth credentials |
Description
PirMei
2021-07-06 15:03:46 UTC
Created attachment 173390 [details]
LibreOffice Draw Document containing a hyperlink with HTTP basic auth credentials
Created attachment 173391 [details]
PDF generated from LibreOffice Draw document containing a hyperlink with HTTP basic auth credentials
I can reproduce with the sample file in comment #1 and 7.0.6: Version: 7.0.6.2 (x64) Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded There are many options in the "Export as PDF" dialog, "Links" tab, and I only tested "Default mode" and "Open with Internet Browser" for "Cross-document Links". Doesn't seem to make a difference, in both cases the link in the PDF points to a (non-existent) local URL. I'm not familiar with the PDF exporting feature though, and there are many options I didn't test, so leaving this at UNCONFIRMED. no repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c5ca46e75e28ba4245d8544ca53c71fea87d1bbd CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL p.s. the link opens in default browser (Microsoft Edge Ver. 91.0.864.71 (official) (64-xx)) and asks for authorization to login I can reproduce this on current git head; it's kind of fun - It almost feels like there's two links in the output - one that's a broken file link , and the 2nd that's a mailto. Looking at the generated pdf, uncompressed with podofouncompress I see: /URI (./https:%2F%2Fusername:password@example.com) Note the './' at the start - so something thinks it's dealing with a relative path. I looked at pdfwriter_impl.cxx:emitLinkAnnotations and it has: if( m_aContext.RelFsys && eBaseProtocol == eTargetProtocol && eTargetProtocol == INetProtocol::File ) bSetRelative = true; printing those values and we see: PDFWriterImpl::emitLinkAnnotations RelFSys: 1 eBaseProtocol: 3 eTargetProtocol: 3 and looking at urlobj.hxx, InetProtocol::File is 3 - so yep, that's been misparsed as a relative file path; not sure by what yet. This looks too easy...but; turning on the m_bUser and m_bPassword flags in urlobj.cxx getSchemeInfo seems to pass a smoke test and produce a pdf with the correct output; I'll check it tomorrow...erm later. @@ -341,7 +343,7 @@ INetURLObject::getSchemeInfo(INetProtocol eTheScheme) "vnd.sun.star.help", "vnd.sun.star.help://", true, false, false, false, false, false, true, true}, SchemeInfo{ - "https", "https://", true, false, false, false, true, true, + "https", "https://", true, true, false, true, true, true, true, true}, SchemeInfo{ "slot", "slot:", false, false, false, false, false, false, false, Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9579737b36e5055d5eb72abc0ace2b9b65600c76 tdf#143216: pdfwriter: Don't treat semi-valid URIs as local paths It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. @buovjaga: <https://bugs.documentfoundation.org/show_activity.cgi?id=143216> has the line > ilmari.lauhakangas@libreoffice.org 2022-02-14 08:18:52 UTC Version unspecified 7.0.6.2 release but without any further explanation here. Is this issue actually a regression? (In reply to Stephan Bergmann from comment #9) > @buovjaga: <https://bugs.documentfoundation.org/show_activity.cgi?id=143216> > has the line > > > ilmari.lauhakangas@libreoffice.org 2022-02-14 08:18:52 UTC Version unspecified 7.0.6.2 release > > but without any further explanation here. Is this issue actually a > regression? That's based on comment 3 Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/da7b06425155938fb0d02c6c178d63fd95ad0cd4 tdf#143216: pdfwriter: Don't treat semi-valid URIs as local paths It will be available in 7.3.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. OK, that should have fixed it. |