Bug 757755 - No authentication dialog for samba printers
Summary: No authentication dialog for samba printers
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon
Version: 28
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-28 15:56 UTC by Alberto Ferrante
Modified: 2018-06-09 00:00 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1121701 (view as bug list)
Environment:
Last Closed: 2018-06-08 11:20:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
screenshot - held for authentication (24.43 KB, image/png)
2012-03-20 22:40 UTC, Michal Ambroz
no flags Details

Description Alberto Ferrante 2011-11-28 15:56:18 UTC
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 16:58:36 UTC
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 21:14:35 UTC
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 22:39:13 UTC
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 22:40:49 UTC
Created attachment 571555 [details]
screenshot - held for authentication

Held for authentication.

Comment 5 Tim Waugh 2012-03-21 15:56:10 UTC
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-04 01:01:38 UTC
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 05:07:00 UTC
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 12:29:23 UTC
Same issue on Fedora 27. Shall we revive this bug or should I file a new bug?

Comment 9 David Auer 2017-12-18 12:31:17 UTC
(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 12:37:57 UTC
This feature has not been added to F27 yet unfortunately, I'm changing version to F27 then.

Comment 11 Marek Kašík 2018-06-08 11:20:19 UTC
This feature has been added to Gnome 3.28 so it is available in Fedora 28.
When a job which needs authentication is created gnome-settings-daemon will show you a notification about it and you can open gnome-control-center's Printers panel by clicking the notification and authenticate the job there.


Note You need to log in before you can comment on or make changes to this bug.