Authentication problem in libcups functions used by pycups

[jpl166]

We have two environments, one which works, one which does not. We're authenticating everything about printing using CUPS 2.2.3 or 2.2.6, and using pycups 1.9.73 to drive. The system works using CUPS 2.2.3 but not 2.2.6.

Digging through the network trace, when we issue a getPrinters in pycups, which calls cupsDoRequest under the covers, I see it pass "Authorization: Basic username:password" (base64 encoded, of course) and the printer list comes back. Then the test script does a printFile, which calls cupsPrintFile2, sending it the same http connection struct, and what goes out on the wire is "Authorization: Basic username:" with no password. This obviously fails hard, since we're requiring valid authentication.

Both servers are FreeBSD 11.1.

We've put in place a bit of a hack workaround by blocking most access to the 2.2.6 server and running without authentication, which works fine. It's not really acceptable in our environment long-term, though.

Our test script:

import cups
cups.setServer("server name")
cups.setEncryption(3)
cups.setPort(631)
def tom(p):
return "password"
cups.setUser("user")
cups.setPasswordCB(tom)
c = cups.Connection()
c.getPrinters()
c.printFile('PRINTER','FILE',"Tom Test",{'document-format':'application/vnd.cups-raw'})

[zdohnal]

Hi,
I think this issue should be reported to cups, because it is cups, who sends request and tries to create job. If it won't be cups bug but change of approach, then I can look into it and find out if python-cups can adapt.
I think the problem in CUPS is with cupsEnumDests(), which doesn't take http connection as parameter and thinks cups as local service -> and when cups, which client is trying to communicate with, authentication isn't done.
So please report to cups project and share link to the issue. I'll close this issue until it will be clear that issue is in python-cups.

[jpl166]

I opened the ticked under both products at once. So far the CUPS folks are pushing a little that it's your problem, although I believe you are correct that it is theirs.

apple/cups#5288