[Libreoffice-bugs] [Bug 126604] New: Linux: Libreoffice doesn't use the keyring when printing to network printer that requires authentication

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=126604

            Bug ID: 126604
           Summary: Linux: Libreoffice doesn't use the keyring when
                    printing to network printer that requires
                    authentication
           Product: LibreOffice
           Version: 6.2.5.2 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: medium
         Component: Printing and PDF export
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: einar at haraldseid.net

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190729/9f112425/attachment.html>