Users must authenticate to print from GTK+ apps

[jdreed]

When printing from GTK+ apps (or, at the very least, gedit and Firefox), users are presented with a dialog requiring them to authenticate. The user's Kerberos password is accepted and results in job submission (and printing). Regular command-line printing works fine and does not require authentication, so I suspect this is an issue of something trying to be smarter than the user.

See  http://web.mit.edu/jdreed/Public/printer-auth.png

[jdreed]

Mark suggests changing AuthType? to None in cupsd.conf

[jdreed]

This looks relevant:

 http://mail.gnome.org/archives/commits-list/2009-September/msg08666.html

Source-diving suggests that the gtk+ backend prompts for a password if:

• The IPP URL returns HTTP 403
• The backend has tried a null password and authentication failed

Someone should fire up Wireshark and compare a GTK+ print job to a command line one.

[jdreed]

The good news is that your print job will be submitted regardless of what you type in the password or username box.

The bad news is that GTK seems to be asking for this authentication just because it can, and not based on any kind of network exchange with cupsd or the print server.

[jdreed]

For maximum kwalitee, the behavior is different depending on whether or not there's a port number in the URL (yes, really).

ipp://cluster-printers.mit.edu/printers/mark-the-great -> works
ipp://cluster-printers.mit.edu:631/printers/mark-the-great -> fails

BrowsePolling?, of course, returns the latter format. Attempting to add a new printer by hand with that URL format causes all sorts of hilarity, including an inability to download a PPD, and foomatic claiming it can't find a PPD for the vendor named "Internet Printing Protocol". (This was tested on stock Lucid, without any debathena packages)

[jdreed]

Here's a terrible idea:

We distribute a printers.conf containing all the things that are normally BrowsePolled?, but we ensure that all URLs don't include the port number. This will get rid of the authentication dialog.

We should still figure out where the bug is (Gtk backend? s-c-p? Both?) and report it.

[jdreed]

Hrm, my theory about the port number may be incorrect. It may be that printers added via s-c-p are fine, but printers added by BrowsePolling? aren't, even when the same URL is used.

[andersk]

/var/cache/cups/remote.cache contains

<Printer ajax>
…
Type 29372438
…
</Printer>

where 29372438 == 0x1c03016 == CUPS_PRINTER_REMOTE | CUPS_PRINTER_BW | CUPS_PRINTER_DUPLEX | CUPS_PRINTER_SMALL | CUPS_PRINTER_MEDIUM | CUPS_PRINTER_AUTHENTICATED | CUPS_PRINTER_COMMANDS | CUPS_PRINTER_DISCOVERED (see cups/cups/cups.h).

By editing remote.cache to change the Type to 25178134 (removing CUPS_PRINTER_AUTHENTICATED), we can get GTK to avoid popping up the auth dialog.

[jdreed]

Awesome. So is this being explicitly set by our print servers, or is an assumption being made somewhere along the way? Or worse, did the meaning of these values change? Certainly our printers _accept_ authentication, but shouldn't require it. I also wonder if, after removing that bit, authenticated operations (e.g. lprm) still work.

[jhamrick]

In looking at the printers.mit.edu printers.conf (i.e. the one on the server), all of the printers have the "require authentication" bit set. In CUPS source, this bit is set when any sort of authentication is set (besides "None"). I need to do more investigation, though, to figure out which parts of server configuration are causing it to be set. It is possible that CUPS is making stuff up, but it is more likely that the server's configuration is causing this to be set.

[jdreed]

So, we can keep working on this, but we need a workaround in place pretty much ~now. I have attached a printers.conf and a classes.conf (we need both) that replicate the current BrowsePolling?. (Note: Printers all show up as type "6". I haven't yet checked to make sure it works on Jaunty, but that's what printers added with s-c-p on Lucid end up as).

We need to create cluster-cupsys-config or something, with the following characteristics:

• it needs to be trivially revertable once we fix the problem, so we should make sure we do versioning and conflicts/replaces correctly.
• it needs to re-divert (or un-divert?) cupsd.conf to turn off BrowsePolling?.
• in the postinst, it needs to, in this order:

-- shut down cups
-- nuke remote.cache
-- nuke /etc/cups/printers.conf and printers.conf.O (that's a capital letter O, not a zero)
-- nuke /etc/cups/classes.conf and classes.conf.O (again, letter not number)
-- drop the new printers.conf and classes.conf into /etc/cups
-- restart cups

[jdreed]

It's possible that we want to not break existing Jaunty machines, and just ship an empty package on platforms with cups 1.3. I'm not sure how best to package that.

[jdreed]

In r24824 and r24825 we have a horrible hack. My understanding is that geofft still wants to test a few more things to see if this can be fixed server-side, but if not, let's go with this, at least in the interim. (Assuming someone other than me has looked at it and tested it).

I'm not building it yet, and cupsys-config is marked as "UNRELEASED" in case we don't end up going with this.

[jdreed]

cupsys-config 1.12, cluster-cups-config 1.0, and cluster 1.7 have all be pushed to development.

[geofft]

Replying to jdreed:

It's possible that we want to not break existing Jaunty machines, and just ship an empty package on platforms with cups 1.3. I'm not sure how best to package that.

Wait up. You seem to do a test for 1.4.3, but this doesn't have anything to do with CUPS version at all, does it? CUPS is doing what it always has, and it's GTK+ that recently learned how to display authentication dialog boxes.

Now, it's the case that the distros with CUPS 1.4 are also the distros with never versions of GTK+, so this is probably fine in practice, but...

[geofft]

Okay, I tested and fixed up Jon's package in r24835, (r24836), r24837, and r24838, and it appears to work, so I'm moving it to -proposed.

As an interesting possible side effect of this change, the system-config-printer popup took until my job finished or at least started printing to appear -- the "printing" icon in the notification area stayed while the printer is warming up.