Created attachment 959405 [details]
Update the job-printer-uri over cups in update_job

Hi,

Now that GTK has the possibility to store printer auth info in gnome-keyring (
https://bugzilla.gnome.org/show_bug.cgi?id=674264 ) and system-config-printer identifies auth_info with the IPP URL (BUG 1089029) they should be compatible. System-config-printer should find credentials stored with GTK and GTK should find them from System config printer.

But in our tests with Fedora 21 where both those changes are active (in GTK3) we noticed that this is not really the case.

Some analysis shows that GTK and system-config-printer "sometimes" have a missmatch between what they think should be the IPP Url.

In my test GTK stores a password with:
uri: ipp://localhost:631/printers/Generic-PDFsmb

This is obtained by a call to:
 gtk_cups_request_ipp_get_string (dispatch->request,
                                  IPP_TAG_URI,
                                  "printer-uri");

The URI is also used to find existing auth_info.

Afaik this should correspond to the job-printer-uri in jobviever.py

In system-config-printer though when I dump the data on a job that should be automatically authenticated through the update job mechanism I see:

 job-printer-uri = ipp://fedora21/printers/Generic-PDFsmb  (fedora21) is the hostname.

The uri with localhost and port is nowhere in this data.
So system-config-printer does not find the auth info and when it saved
it is not found in GTK.

If I then explicitly click authenticate in the system-config-printer menu we go
down through on_job_authenticate_activate and there we get the uri:

 job-printer-uri = ipp://localhost:631/printers/Generic-PDFsmb

Similary if I close system-config-printer and restart it on the next automatic update job i also get:

 job-printer-uri = ipp://localhost:631/printers/Generic-PDFsmb

And everything is fine!

But this does not help when the first call used the other URI and an entry
with the URI using the hostname was created.

I've added a backtrace in the bad case and it turned out that the problematic
URI came through job_event. In monitor.py dumping the event shows that
the notify-printer-uri in the event is the "ipp://fedora21/printers/Generic-PDFsmb" and thus the wrong one. I did not find the correct URI in the event  and as this comes from the Cups connection I don't think that we can do much to get the correct URI there.

Please see attached patch. It updates the job-printer-uri together with the other job-attributes in update_job and is mostly a comment to explain why the job-printer-uri is requested again as a job attribute even if it was already set earlier. 


There is now still an issue that GTK does not use an entry created by
system-config-printer but this is likely a problem in GTK, I'm debugging it from
there.