Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auth-info-required not set on browsed printer #2750

Closed
michaelrsweet opened this issue Mar 11, 2008 · 4 comments
Closed

auth-info-required not set on browsed printer #2750

michaelrsweet opened this issue Mar 11, 2008 · 4 comments
Labels
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

@michaelrsweet michaelrsweet commented Mar 11, 2008

Version: 1.3.6
CUPS.org User: twaugh.redhat

When using CUPS 1.3.6 as a client to a remote CUPS queue, the auth-info-required attribute is not set on the client's queue.

  1. Set up a CUPS server on the network and share a queue using CUPS Browsing. Add this policy fragment:

    AuthType Basic Require valid-user

so that authentication is required before a job can be submitted.

  1. Configure a CUPS 1.3.6 client to discover browsed printers using CUPS Browsing
  2. On this client machine, submit a print job to the browsed queue. The job will stop because authentication is required.
  3. Send a Get-Job-Attributes IPP request for that job to the client, and observe that job-hold-until=='auth-info-required'
  4. Send a Get-Printer-Attributes IPP request for the browsed printer to the client, and observe that there is no 'auth-info-required' attribute.

Although auth_info_required has (presumably) been set in the printer structure, no 'auth-info-required' attribute has been created for it.

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Mar 19, 2008

CUPS.org User: mike

Reducing priority to 3.

Can you supply a debug2 error_log file from the client showing the incoming browse packets (or just a tcpdump of the browse packets)?

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Apr 2, 2008

CUPS.org User: twaugh.redhat

I think I've found the problem. With 1.3.7, here is what happens:

The client CUPS scheduler sees the browsed printer, with 'auth-info-required' set.

The CUPS client, lp, submits the job on the local machine, and the client CUPS scheduler asks for authentication at that stage, due to the remote printer requiring authentication. This is performed using SO_PEERCRED, and results in an auth file containing only the username -- no password.

The local 'ipp' backend starts, and sees AUTH_USERNAME='tim' and AUTH_PASSWORD='' (empty string) in its environment. As AUTH_PASSWORD is set, it uses that (the empty string) as the password in the password callback and of course this fails. The main request then fails and so auth-info-required is set to 'negotiate', which is incorrect.

The fix is to get the 'ipp' backend to avoid sending the empty string as the password. Patch attached -- and with this patch, I can finally get proxy authentication working with CUPS.

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Apr 21, 2008

CUPS.org User: mike

Patch looks good to me - we don't even support authentication without a password...

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Apr 21, 2008

"cups-fix-auth.patch":

diff -up cups-1.3.7/backend/ipp.c.fix-auth cups-1.3.7/backend/ipp.c
--- cups-1.3.7/backend/ipp.c.fix-auth 2008-04-02 18:43:37.000000000 +0100
+++ cups-1.3.7/backend/ipp.c 2008-04-02 18:43:27.000000000 +0100
@@ -1483,7 +1483,7 @@ password_cb(const char prompt) / I -
{
(void)prompt;

  • if (password && password_tries < 3)
  • if (password && *password && password_tries < 3)
    {
    password_tries ++;
@michaelrsweet michaelrsweet added this to the Stable milestone Mar 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.