Red Hat Bugzilla – Full Text Bug Listing
|Summary:||No authentication dialog for samba printers|
|Product:||[Fedora] Fedora||Reporter:||Alberto Ferrante <alberto_ferrante>|
|Component:||gnome-settings-daemon||Assignee:||Marek Kašík <mkasik>|
|Status:||ASSIGNED ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||27||CC:||bnocera, dreua, jpopelka, mclasen, mishu, mkasik, rebus, rstrode, tuksgig, twaugh|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||1121701 (view as bug list)||Environment:|
|Last Closed:||2013-08-01 01:06:53 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Alberto Ferrante 2011-11-28 10:56:18 EST
Description of problem: When a Samba printer is configured and the option "prompt user if authentication is required", no authentication is shown when the user tries to print (except in Firefox/Thunderbird and GIMP) and the job is held for authentication. Version-Release number of selected component (if applicable): Any (1.4 and 1.5) How reproducible: Always Steps to Reproduce: 1. Create a new samba printer and choose "prompt user if authentication is required" 2. Print any document in any application (except Firefox/Thunderbird and GIMP) Actual results: The printout is held for authentication Expected results: A popup asking for Windows username and password should be shown and the printout should be sent to the printer by using these authentication information. Additional info: On the CUPS forums they say it is not a CUPS problem, but it is a problem of the tool-kits: http://www.cups.org/newsgroups.php?s8054+gcups.bugs+v8063+T0
Comment 1 Tim Waugh 2011-12-13 11:58:36 EST
Alberto: are you using Fedora 15, or Fedora 16? Also, is this with the GNOME desktop, or with KDE?
Comment 2 Alberto Ferrante 2011-12-13 16:14:35 EST
We are using Fedora 15, but I tested it also on Fedora 16 with the same results. Actually, this is a long-standing problem, to my knowledge, it was there already in Fedora 10-11. The behavior is the same both in Gnome and in KDE. Regards, Alberto
Comment 3 Michal Ambroz 2012-03-20 18:39:13 EDT
I can confirm the same wrong behaviour remains in Fedora 17 when printing from some applications. Instead of raising pop-up prompt for authentication the job remains in the printer queue forever with status pending for authentication. cups-1.5.2-6.fc17.x86_64 cups-bjnp-1.0-2.fc17.x86_64 cups-ipptool-1.5.2-6.fc17.x86_64 cups-libs-1.5.2-6.fc17.x86_64 cups-lpd-1.5.2-6.fc17.x86_64 cups-pdf-2.6.1-1.fc17.x86_64 cups-pk-helper-0.2.1-3.fc17.x86_64 samba-3.6.3-80.fc17.1.x86_64 samba-client-3.6.3-80.fc17.1.x86_64 samba-common-3.6.3-80.fc17.1.x86_64 system-config-printer-1.3.9-1.fc17.x86_64 system-config-printer-libs-1.3.9-1.fc17.x86_64 system-config-printer-udev-1.3.9-1.fc17.x86_64 control-center-3.3.91-1.fc17.x86_64 gnome-shell-3.3.90-2.fc17.x86_64 I have tested printing with following applications: Authentication NOT Displayed: - system-config-printer - print test page - libreoffice impress - libreoffice writer (!!!) - Adobe Acrobat Reader (!!!) - Quanta - qt designer - printing from commandline: echo "TEST"| lp gsview dia Authentication Displayed correctly: - firefox - thunderbird - chrome - evince - anjuta - gimp - gedit - seems to be OK from all native gtk applications I would say that it is great it works fine from most GTK applications. Problem is that it doesn't work for most common printing use-case = printing from the libreoffice writer :(. Michal Ambroz
Comment 4 Michal Ambroz 2012-03-20 18:40:49 EDT
Created attachment 571555 [details] screenshot - held for authentication Held for authentication.
Comment 5 Tim Waugh 2012-03-21 11:56:10 EDT
There are two cases where authentication should be prompted: 1. When a job sent to a queue whose backend requires authentication information fails because either: i. no authentication information was provided, or ii. the wrong authentication information was provided and 2. When a job is about to be sent to a queue which we know from previous experience requires authentication When a queue is first set up, there is no way to know whether it will require authentication until after we've submitted a job to it. However, once the job fails due to lack of authentication information, CUPS marks the queue with an auth-info-required attribute so that we know to provide it in future along with the job. So, the way it is meant to work is this: The first time a job is sent to the queue, the job will fail pending authentication. The desktop session should spot this and prompt for authentication, then provide that info to the job using an IPP-Authenticate-Job request. Next time a job is to be sent to that queue, the print dialog should see that auth-info-required is set and prompt for authentication. The job should then succeed, provided the correct info was provided. However: the job may still fail if the auth info was wrong, in which case -- as with the first job sent -- the desktop session should spot that the job requires authentication and should prompt the user for it. Where I've written "the print dialog" above, I'm talking about the GTK+ print dialog. For print dialogs that are not aware of authentication, they ought to be fixed; where this is not possible, the scenario will play out just as with the first job submitted -- the job will fail pending authentication, and the desktop session needs to finish it off by asking the user for their auth info. It looks like everything is in place except for the part where the desktop session spots jobs that are pending authentication, and provides it to them. Prior to GNOME 3, this functionality was part of system-config-printer-applet. Did that get lost in the transition to the gnome-settings-daemon printer notifications?
Comment 6 Fedora End Of Life 2013-07-03 21:01:38 EDT
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 7 Fedora End Of Life 2013-08-01 01:07:00 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 8 David Auer 2017-12-18 07:29:23 EST
Same issue on Fedora 27. Shall we revive this bug or should I file a new bug?
Comment 9 David Auer 2017-12-18 07:31:17 EST
(In reply to David Auer from comment #8) > Same issue on Fedora 27. Shall we revive this bug or should I file a new bug? Sorry, typo: I meant Fedora 26. Haven't tested it on F27 yet.
Comment 10 Marek Kašík 2017-12-18 07:37:57 EST
This feature has not been added to F27 yet unfortunately, I'm changing version to F27 then.