When attempting configuring a printer e.g. from a central CUPS server which responds to the POST /admin/ HTTP/1.1 request with 403 (Forbidden), configure-printer enters and endless loop, retrying and retrying the "POST" tens of times per second. This leads to severe network contention and fills the logfiles of CUPS servers, so I regards this as a major issue in environments with a central CUPS server. As a solution, only killing "configure-printer" or restarting KDE helps. To reproduce: Enter the printer configuration via PlasmaShells tray, configure any printer from a central cups server, and click "Apply". Let me know if more info is needed.
I believe the endless loop starts here: https://github.com/KDE/print-manager/blob/afd4609014e9aa938cb02be858f880deb56ade8e/libkcups/KCupsRequest.cpp#L564
That line is only a problem if there is a programming error with Qt parenting, which is unlikely. What can help here is the server configuration tho I sadly don't have much more time to investigate issues on this.
Well, if the server responds with 403 but the client retries (endlessly), I'd say it's clearly a client-side bug. So something must go wrong with the error handling in the forked connection thread. The related CUPS server config part is: <Location /admin> Order allow,deny Allow from INSERTADMINHOSTIPHERE </Location> Of course I am trying from a normal client, not the admin machine.
You made me have a deeper look at the code, the bug is obvious in: https://github.com/KDE/print-manager/blob/master/libkcups/KCupsConnection.cpp 1) KCupsConnection::request() calls retry(). 2) KCupsConnection::retry() handles (status == IPP_FORBIDDEN), and if password_retries == 0, will set force_auth to true. 3) If force_auth is true, cupsDoAuthentication will be called. 4) cupsDoAuthentication will NOT call the password_cb callback, since it will (again) get a 403. for this reason, password_retries will NOT be bumped. 5) Since cupsDoAuthentication returned -1, KCupsConnection::retry() will return true. 6) We go back to Step 1. That will happen endlessly. On a side-note, debug output is broken: qCDebug(LIBKCUPS) << "Called cupsDoAuthentication(), success:" << (ret == -1 ? true : false); Here "-1" indicates failure, not success. Does this help to resolve the issue?
If you allow for a comment: I'd say relying on the callback function to work (and thus relying on cups API callback behaviour to break the loop) is not a good idea in general. Maybe, at least as additional safety, it is better to have an additional exit condition.
Can you confirm my understanding of the code is correct? If yes, and you tell me which way you prefer it to be solved: a) adding an additional error counting mechanism independent from the callback b) immedate erroring if 403 is received when attempted as root user c) both I could also prepare a PR.
To be honest I'm not sure what is best. I think b is received if the password is wrong, but I'm not sure (old code :P) if you can try both solutions would be great, I'll have more time to look into this in around 2 weeks, so please ping me. Thanks.
Hi, it seems you are correct, the CUPS server may also return 403 if the user uses a wrong password (I was pretty sure it would return NOT_AUTHENTICATED or NOT_AUTHORIZED in that case...). Based on that, I have created a very generic fix: https://github.com/KDE/print-manager/pull/2 It works for me against a CUPS-Server with IP whitelist / blacklist (i.e. no endless loop anymore!), and I can still authenticate to a local CUPS as root.
Hi, just to document: I have now uploaded the PR, as seems to be the correct way for KDE contributions, to: https://phabricator.kde.org/D7325
Hi, here the friendly "ping", as requested. Cheers, Oliver
Committed as https://commits.kde.org/print-manager/9da623e104ea2dd79041f3608f5f196383441c4c