Bug 757755 - No authentication dialog for samba printers
No authentication dialog for samba printers
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
17
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Marek Kašík
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-28 10:56 EST by Alberto Ferrante
Modified: 2015-12-16 10:01 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1121701 (view as bug list)
Environment:
Last Closed: 2013-08-01 01:06:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
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.

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