Open Radar

 
The CUPS ipp backend in OSX 10.7.3 does not ask for username and password to do a HTTP1.1 Basic authorization.

Earlier we have reported this problem occuring which started with CUPS 1.5 in OSX 10.7

The short version is that the /usr/libexec/cups/backend/ipp needs some fixing.

To show you what we have tried and what we did to come to this conclusion we have a longer version below.
Please read it and perform the same tests yourself. All tests are described in detail with explanation.

Here is a step by step guide how to replicate our troublesome situation with two computers both running OSX 10.7.3:

Set up a server computer to share printers.
Set up a printer on the server computer. Share this printer.
Allow printing from the internet. This will put something like this in /etc/cups/cupd.conf:

<Location />
 # Allow remote access...
 Order allow,deny
 Allow all
</Location>

Any computer should now be able to print to your shared printer.

Add the shared printer to your client computer using IPP printing.

Test that you can print f.ex a test page on the printer. Once you have verified this step, continue.

Change the cups configuration on your server computer to use HTTP1.1 Basic authorization.
You will have change the Location section in /etc/cups/cupsd.conf like this:

<Location />
 # Allow remote access...
 Order allow,deny
 Allow from 127.0.0.1
 Satisfy Any
 AuthType Basic
</Location>

Restart cupsd on the server computer doing this:

	sudo launchctl unload /System/Library/LaunchDaemons/org.cups.cupsd.plist
	sudo launchctl load /System/Library/LaunchDaemons/org.cups.cupsd.plist

Now the /usr/libexec/cups/backend/ipp program on the client computer should pop up a dialog box asking for a username and password. This does not happen. Even if we alter the printers.conf file by running this command:

	lpadmin -p myprinter -o auth-info-required=username,password

If your printer name was "myprinter".

The /usr/libexec/cups/backend/ipp needs to be fixed so that it correctly asks for username and password and then correctly authorize itself against the printing server.

We have run simle tests authenticating against the printing server using both openssl and curl.

Simply using curl to see a message from the server requiring an upgrade:

	curl -k http://myserver.my.net:631/printers/myprinter

Given that your server name is my.server.net and the printer name is myprinter.
I will use this in the following examples.

Now to do HTTP/1.1 Basic authentication using cups we can do this:

	curl -k -u greg:beerlover https://myserver.my.net:631/printers/myprinter

Of course, you can also bring up https://myserver.my.net:631/printers/myprinter in your favourite browser.
Your browser will then ask you for a username and a password. Like the ipp backend should have done.

Looking at these things with curl does only show of the communication between your computer and the printer server.
To check things more thorough, we used the openssl program.

To do HTTP/1.1 Basic authentication one simply supplies a base64 coded version of username:password in the Authorization: header. So we do this:

	echo -n greg:beerlover | base64

which gives us this:

	Z3JlZzpiZWVybG92ZXIK

assuming that the username you wanted to test with was "greg" and his password was "beerlover".
Please do not forget to give the "-n" option to the echo command. If you forget, your authentication string will be wrong.

First lets try without authenticating:

	openssl s_client -connect myserver.my.net:631

Then type the following line followed by hitting the enter key twice to make a blank line.

	GET /printers/myprinter HTTP/1.1

You should now now receive a HTTP/0.9 401 Unauthorized with all the info you need to authenticate.
The headers will tell you to use TLS/1.0 and HTTP/1.1 Basic authentication.

Now we will connect again and use HTTP/1.1 Basic authentication:

	openssl s_client -connect myserver.my.net:631

Then type the following line followed by hitting the enter key twice to make a blank line.

	GET /printers/myprinter
	Authorization: Basic Z3JlZzpiZWVybG92ZXIK

You should now be authorized to access the printer page.

Obviously, if you can manually do HTTP/1.1 Basic authentication to the CUPS printer server using a browser or the curl or openssl programs, the /usr/libexec/cups/backend/ipp program can too. If it asks you for your username and password.

I'll go on and supply some output from the computers logs and output when running the ipp backend manually.

Running the ipp backend gives this:

bash-3.2# /usr/libexec/cups/backend/ipp.orig 43 eskil testprint 1 AP_ColorMatchingMode=AP_ApplicationColorMatching AP_D_InputSlot= collate com.apple.print.DocumentTicket.PMSpoolFormat=application/pdf com.apple.print.JobInfo.PMJobName=testprint com.apple.print.PrinterInfo.PMColorDeviceID..n.=1656 com.apple.print.PrintSettings.PMColorMatchingMode..n.=0 com.apple.print.PrintSettings.PMColorSyncProfileID..n.=1294 com.apple.print.PrintSettings.PMCopies..n.=1 com.apple.print.PrintSettings.PMCopyCollate..b. com.apple.print.PrintSettings.PMFirstPage..n.=1 com.apple.print.PrintSettings.PMLastPage..n.=2147483647 com.apple.print.PrintSettings.PMPageRange..a.0..n.=1 com.apple.print.PrintSettings.PMPageRange..a.1..n.=2147483647 fit-to-page media=A4 pserrorhandler-requested=standard job-uuid=urn:uuid:611f66ec-5959-3112-6638-61182b8726f4 job-originating-host-name=localhost time-at-creation=1328881736 time-at-processing=1328881994 PageSize=A4
DEBUG: 21 files to send in job...
DEBUG: update_reasons(attr=0(), s="+connecting-to-device")
DEBUG2: op='+', new_reasons=1, state_reasons=1
STATE: +connecting-to-device
DEBUG: Looking up "od-prod01.uio.no"...
DEBUG2: hrDeviceDesc="Unknown"
DEBUG: prtGeneralCurrentLocalization type is 0, expected 2!
DEBUG: Connecting to od-prod01.uio.no:631
INFO: Kobler til skriver.
DEBUG: update_reasons(attr=0(), s="-cups-certificate-error")
DEBUG2: op='-', new_reasons=1, state_reasons=2
DEBUG: update_reasons(attr=0(), s="-connecting-to-device")
DEBUG2: op='-', new_reasons=1, state_reasons=2
STATE: -connecting-to-device
INFO: Tilkoblet skriver.
DEBUG: Connected to 129.240.0.104:631...
DEBUG: Getting supported attributes...
DEBUG: Get-Printer-Attributes: cups-authorization-canceled (Uautorisert)
DEBUG: Get-Printer-Attributes returned cups-authorization-canceled.
ERROR: Kan ikke hente skriverstatus.
DEBUG: Getting supported attributes...
DEBUG: Get-Printer-Attributes: cups-authorization-canceled (Uautorisert)
DEBUG: Get-Printer-Attributes returned cups-authorization-canceled.
ERROR: Kan ikke hente skriverstatus.
DEBUG: Getting supported attributes...

and so on and so on ....

Here are some interesting lines from the server computers /var/log/cups/error_log

D [10/Feb/2012:15:51:24 +0100] Connection from 129.240.12.28 now encrypted.
E [10/Feb/2012:13:37:51 +0100] Bad request line "%17%03%01%02p%CBv%D0%F6+%C5I%BFk%07%B9|{;q%E9O"q%C9F%86%89(" from 193.157.196.146!
D [10/Feb/2012:15:51:24 +0100] cupsdAuthorize: No authentication data provided.