When exporting documents including hyperlinks with HTTP basic authentication credentials from any application (tested with Draw, Writer and Calc) to PDF, the hyperlink gets lost and somehow points to local resources/paths which cannot be found.
Steps to Reproduce:
1.Create a hyperlink in any document in the format of http://username:email@example.com
2. Open the link to confirm it is working by CTRL+clicking the link (this works from within LibreOffice)
3. Export the document to PDF via File - Export as... - Export as PDF
4. Open the exported PDF
5. Try to open the hyperlink with basic auth credentials from within the PDF viewer (tested: Okular, SumatraPDF under Wine)
Either the PDF viewer says it can't find the specified local resource or opens some random path in the file manager (in my case thunar)
The link should be opened in the default web browser and try to log in to the website requiring HTTP basic authentication using the provided credentials.
User Profile Reset: Yes
Version: 18.104.22.168 / LibreOffice Community
Build ID: 10(Build:2)
CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
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: 22.214.171.124 (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
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: 126.96.36.199.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
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:
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},
- "https", "https://", true, false, false, false, true, true,
+ "https", "https://", true, true, false, true, true, true,
"slot", "slot:", false, false, false, false, false, false, false,