Bug 126604 - Linux: Libreoffice doesn't use the keyring when printing to network printer that requires authentication
Summary: Linux: Libreoffice doesn't use the keyring when printing to network printer t...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.2.5.2 release
Hardware: All Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-29 21:47 UTC by Einar Jørgen Haraldseid
Modified: 2022-11-08 10:57 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example of disabling the Libre Office version of print dialogs in an earlier version (46.03 KB, image/jpeg)
2022-11-08 10:55 UTC, Sral
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Einar Jørgen Haraldseid 2019-07-29 21:47:05 UTC
Description:
A very common printing setup in universities/education and large companies is to have network printers shared via Windows File and Printer services, using the Active Directory accounts for authentication. 

The optimal way to connect to such printers on Linux is to add it as a local queue in CUPS, with smb://WORKGROUP/servername.example.com/sharedprinter as a remote path, and with the option "AuthInfoRequired" set to "username,password". This is then exposed as i.e. ipp://localhost:631/printers/QueueName

In this setup, whenever a user tries to print, a popup comes up, asking for username and password. This popup is presented every time a user tries to print.

It would be nice if LibreOffice was able to use the proper credentials from the system keyring. Other programs, notably Firefox, Google Chrome and all native GTK3 apps are able to do this.

This is an example on how it looks in the keyring for a queue named QueueName:

$ secret-tool search uri ipp://localhost:631/printers/PrintQueue
[/org/freedesktop/secrets/collection/login/14837]
label = ipp://localhost:631/printers/PrintQueue
secret = correct horse battery staple
created = 2019-07-29 21:35:31
modified = 2019-07-29 21:35:31
schema = org.freedesktop.Secret.Generic
attribute.uri = ipp://localhost:631/printers/PrintQueue
attribute.user = exampleuser

Note: A workaround is to store the credentials directly in the printer path in the cups config as smb://WORKGROUP/username:password@servername.example.com/sharedprinter, but this is considered unsafe, and wouldn't work on a multiuser system.

Steps to Reproduce:
1. Set up a network printer shared from a Windows server, don't store the credentials in the printer share path
2. Make sure credentials are stored in the keyring (a popup when printing from i.e. gedit will usually have a checkbox for storing the credentials)
3. Try printing from a LibreOffice application

Actual Results:
User is prompted for credentials, even though the credentials are present in the keyring

Expected Results:
LibreOffice finds the credentials in the keyring and uses them.

Or possibly: the print job is handed over to the host system in a different manner than today, negating the need for a built-in popup for this (see: Firefox, Google Chrome)


Reproducible: Always


User Profile Reset: Yes



Additional Info:
I have tested this on multiple modern distributions, with an eye to making printing for our students and staff at NTNU more accessible and easier.
Comment 1 Xisco Faulí 2020-05-11 08:25:27 UTC
Thanks for reporting this issue.
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 2 Klais 2020-11-16 20:29:35 UTC Comment hidden (spam)
Comment 3 Clayton Jimmy 2021-01-27 13:13:58 UTC Comment hidden (spam)
Comment 4 Elsa Avend 2021-03-18 19:45:53 UTC Comment hidden (spam)
Comment 5 John Williams 2022-01-26 20:30:24 UTC
This behaviour persists in 2022, AFAICT. and is extremely frustrating.

Or is there some solution? I've Googled for this many times over the years, to no avail. Perhaps I've not looked hard enough?

LO Community 7.2.5.2 on Fedora 35.
Comment 6 Sral 2022-11-08 10:55:35 UTC
Created attachment 183467 [details]
Example of disabling the Libre Office version of print dialogs in an earlier version

In older LibreOffice version you could disable the LibreOffice print dialog and instead use the one supplier with the operating system.
Comment 7 Sral 2022-11-08 10:57:56 UTC
Agree. This behavior persists in 2022. Currently using 7.3.6.2 in Linux.

However. There was a work around just 2 years back which has been removed. You could change the printer dialogue to use the one the operating system has and then it worked since that can connect to a "keyring".

Tools -> Options -> LibreOffice -> General. And there uncheck the 
"Print Dialogs" Use LibreOffice dialogs.

(If I remember right you had to change a setting somewhere else in the settings to see the Print Dialogs setting)