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.

Sign up for GitHub

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

Jump to bottom

Chrome doesn't support concatenation of WWW-Authenticate values #5289

Closed
ajacoutot opened this issue Apr 7, 2018 · 17 comments
Closed

Chrome doesn't support concatenation of WWW-Authenticate values #5289

ajacoutot opened this issue Apr 7, 2018 · 17 comments
Assignees
@michaelrsweet
Labels
priority-low
Milestone
CUPS 2.2.x Updates

Comments

@ajacoutot
Copy link

ajacoutot commented Apr 7, 2018 •
edited by michaelrsweet

Hi.

The login promt dialog is never displayed on the web interface since I moved from 2.2.6 to 2.2.7 on OpenBSD. I'm running with the "Fixed builds without PAM (Issue #5283)" patch.
I can't add printer or anything...

D [07/Apr/2018:17:12:53 +0200] [Client 148] POST /admin/ HTTP/1.1
D [07/Apr/2018:17:12:53 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Not busy"
D [07/Apr/2018:17:12:53 +0200] [Client 148] Read: status=200, state=6
D [07/Apr/2018:17:12:53 +0200] [Client 148] No authentication data provided.
D [07/Apr/2018:17:12:53 +0200] [CGI] argv[0] = "/usr/local/libexec/cups/cgi-bin/admin.cgi"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[0] = "CUPS_CACHEDIR=/var/cache/cups"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[1] = "CUPS_DATADIR=/usr/local/share/cups"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[2] = "CUPS_DOCROOT=/usr/local/share/doc/cups"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[3] = "CUPS_FONTPATH=/usr/local/share/cups/fonts"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[4] = "CUPS_REQUESTROOT=/var/spool/cups"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[5] = "CUPS_SERVERBIN=/usr/local/libexec/cups"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[6] = "CUPS_SERVERROOT=/etc/cups"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[7] = "CUPS_STATEDIR=/var/run/cups"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[8] = "HOME=/var/spool/cups/tmp"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[9] = "PATH=/usr/local/libexec/cups/filter:/usr/local/bin:/usr/local/sbin:/bin:/usr/bin"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[10] = "[email protected]"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[11] = "SOFTWARE=CUPS/2.2.7"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[12] = "TMPDIR=/var/spool/cups/tmp"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[13] = "USER=root"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[14] = "CUPS_MAX_MESSAGE=2047"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[15] = "CUPS_SERVER=/var/run/cups/cups.sock"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[16] = "CUPS_ENCRYPTION=IfRequested"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[17] = "IPP_PORT=631"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[18] = "LANG=en_US.UTF8"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[19] = "REDIRECT_STATUS=1"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[20] = "GATEWAY_INTERFACE=CGI/1.1"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[21] = "SERVER_NAME=localhost"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[22] = "SERVER_PORT=631"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[23] = "REMOTE_ADDR=[v1.::1]"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[24] = "REMOTE_HOST=localhost"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[25] = "SCRIPT_NAME=/admin/"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[26] = "SCRIPT_FILENAME=/usr/local/share/doc/cups/admin/"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[27] = "SERVER_PROTOCOL=HTTP/1.1"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[28] = "HTTP_COOKIE=cookieconsent_status=dismiss; cookieconsent_status=dismiss; org.cups.sid=3b2299ace89dd9949d0d05f9b5377e83; _ga=GA1.1.400730187.1498486944; sessionLang=en; _gid=GA1.1.873084023.1498486944; sessionUrl=https%253A%2F%2Flocalhost%253A8043%2F"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[29] = "HTTP_USER_AGENT=Mozilla/5.0 (X11; OpenBSD amd64; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[30] = "HTTP_REFERER=http:https://localhost:631/admin"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[31] = "REQUEST_METHOD=POST"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[32] = "CONTENT_LENGTH=60"
D [07/Apr/2018:17:12:53 +0200] [CGI] envp[33] = "CONTENT_TYPE=application/x-www-form-urlencoded"
D [07/Apr/2018:17:12:53 +0200] [CGI] Started /usr/local/libexec/cups/cgi-bin/admin.cgi (PID 46991)
I [07/Apr/2018:17:12:53 +0200] [Client 148] Started "/usr/local/libexec/cups/cgi-bin/admin.cgi" (pid=46991, file=23)
D [07/Apr/2018:17:12:53 +0200] [Client 148] Waiting for CGI data.
I [07/Apr/2018:17:12:53 +0200] Expiring subscriptions...
D [07/Apr/2018:17:12:53 +0200] [CGI] admin.cgi started...
D [07/Apr/2018:17:12:53 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Active clients"
D [07/Apr/2018:17:12:53 +0200] [Client 154] Server address is "/var/run/cups/cups.sock".
D [07/Apr/2018:17:12:53 +0200] [Client 154] Accepted from localhost (Domain)
D [07/Apr/2018:17:12:53 +0200] [Client 154] Waiting for request.
D [07/Apr/2018:17:12:53 +0200] [CGI] http=0xa62aa71d000
D [07/Apr/2018:17:12:53 +0200] [CGI] cgiSetVariable: SECTION=\"admin\"
D [07/Apr/2018:17:12:53 +0200] [CGI] cgiSetVariable: REFRESH_PAGE=\"\"
D [07/Apr/2018:17:12:53 +0200] [CGI] org.cups.sid cookie is \"3b2299ace89dd9949d0d05f9b5377e83\"
D [07/Apr/2018:17:12:53 +0200] [CGI] cgiSetVariable: org.cups.sid=\"3b2299ace89dd9949d0d05f9b5377e83\"
D [07/Apr/2018:17:12:53 +0200] [CGI] cgiSetVariable: OP=\"add-printer\"
D [07/Apr/2018:17:12:53 +0200] [CGI] op=\"add-printer\"...
D [07/Apr/2018:17:12:53 +0200] [CGI] do_am_printer: DEVICE_URI=\"(null)\"
D [07/Apr/2018:17:12:53 +0200] [CGI] Getting list of devices...
D [07/Apr/2018:17:12:53 +0200] [Client 154] POST / HTTP/1.1
D [07/Apr/2018:17:12:53 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Active clients"
D [07/Apr/2018:17:12:53 +0200] [Client 154] Read: status=200, state=6
D [07/Apr/2018:17:12:53 +0200] [Client 154] No authentication data provided.
D [07/Apr/2018:17:12:53 +0200] [Client 154] Read: status=100, state=6
D [07/Apr/2018:17:12:53 +0200] [Client 154] Read: status=100, state=6
D [07/Apr/2018:17:12:53 +0200] [Client 154] Read: status=100, state=6
D [07/Apr/2018:17:12:53 +0200] [Client 154] Read: status=100, state=6
D [07/Apr/2018:17:12:53 +0200] [Client 154] 2.0 CUPS-Get-Devices 1
D [07/Apr/2018:17:12:53 +0200] CUPS-Get-Devices
D [07/Apr/2018:17:12:53 +0200] cupsdIsAuthorized: username=""
D [07/Apr/2018:17:12:53 +0200] [Client 154] Returning HTTP Unauthorized for CUPS-Get-Devices (no URI) from localhost
D [07/Apr/2018:17:12:53 +0200] [Client 154] cupsdSendHeader: code=401, type="text/html", auth_type=0
D [07/Apr/2018:17:12:53 +0200] [Client 154] WWW-Authenticate: Basic realm=\"CUPS\", PeerCred, Local trc=\"y\"
D [07/Apr/2018:17:12:53 +0200] [CGI] cgi_passwd(prompt=\"Password for _cups on localhost? \") called!
D [07/Apr/2018:17:12:53 +0200] [Client 148] CGI data ready to be sent.
D [07/Apr/2018:17:12:53 +0200] [Client 154] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
D [07/Apr/2018:17:12:53 +0200] [Client 154] Closing connection.
D [07/Apr/2018:17:12:53 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Active clients"
D [07/Apr/2018:17:12:53 +0200] [Client 148] con->http=0x83deb1bf000
D [07/Apr/2018:17:12:53 +0200] [Client 148] cupsdWriteClient error=0, used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=2147483647, response=0x0(), pipe_pid=46991, file=23
D [07/Apr/2018:17:12:53 +0200] [Client 148] Waiting for CGI data.
D [07/Apr/2018:17:12:53 +0200] [Client 148] Script header: Status: 401
D [07/Apr/2018:17:12:53 +0200] [Client 148] Script header: 
D [07/Apr/2018:17:12:53 +0200] [Client 148] Sending status 401 for CGI.
D [07/Apr/2018:17:12:53 +0200] [Client 148] cupsdSendHeader: code=401, type="text/html", auth_type=0
D [07/Apr/2018:17:12:53 +0200] [Client 148] WWW-Authenticate: Basic realm=\"CUPS\", Local
D [07/Apr/2018:17:12:53 +0200] [Client 148] Flushing write buffer.
D [07/Apr/2018:17:12:53 +0200] [Client 148] New state is HTTP_STATE_WAITING
D [07/Apr/2018:17:12:53 +0200] [Client 148] Waiting for request.
D [07/Apr/2018:17:12:53 +0200] [Client 148] Closing because Keep-Alive is disabled.
D [07/Apr/2018:17:12:53 +0200] [Client 148] Closing connection.
D [07/Apr/2018:17:12:53 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Active clients"
D [07/Apr/2018:17:12:53 +0200] PID 46991 (/usr/local/libexec/cups/cgi-bin/admin.cgi) exited with no errors.
@michaelrsweet
Copy link
Collaborator

OK, the log fragment you sent shows the 401 status being sent to the web browser, but no authentication data being sent from the browser to cupsd.

What browser are you using?

What version of OpenBSD?

@michaelrsweet michaelrsweet self-assigned this Apr 9, 2018
@michaelrsweet michaelrsweet added the investigating Investigating the issue label Apr 9, 2018
@ajacoutot
Copy link
Author

Ohoh my bad... yes you're right, that's a brower issue.
Using chromium fails but it works fine with firefox and epiphany.
Closing since it's clearly not a CUPS bug :-)
Thanks @michaelrsweet

@Chais
Copy link

Chais commented Apr 16, 2018 •
edited

Facing the same exact problem it might still be interesting to know what the actual issue is. If it is indeed a bug in chromium, fine. But if chromium deliberately changed its behaviour it may be wise to adapt CUPS accordingly. Otherwise chromium would end up being permanently unsupported.

@michaelrsweet
Copy link
Collaborator

Chrome cowardly stopped supporting self-signed certificates, at all. Nothing we can do to "adapt" short of dropping the web interface... We already support Let's Encrypt and other CA-sign certs.

@Chais
Copy link

Chais commented Apr 16, 2018

I see. Does basic auth always use encryption? Because I'm seeing this with plain http.

@michaelrsweet
Copy link
Collaborator

Basic auth (RFC 7617) does not explicitly allow it, but Chromium requires it.

@Chais
Copy link

Chais commented Apr 16, 2018

Oof. OK then. Firefox it is… Thanks for the insights.

@foutrelis
Copy link

The problem seems to be the ", Local" part appended to the "WWW-Authenticate" response header. Chromium doesn't seem to like it for some reason!

@michaelrsweet
Copy link
Collaborator

Hmm, sounds like chromium isn't supporting HTTP properly (!).

WWW-Authenticate is one of the (many) HTTP headers that follows value concatenation rules...

We can probably filter out the ", Local" part for non-CUPS clients, but ultimately Google needs to fix Chrome...

@michaelrsweet michaelrsweet reopened this Apr 16, 2018
@michaelrsweet michaelrsweet changed the title login prompt is never displayed Chrome doesn't support concatenation of WWW-Authenticate values Apr 16, 2018
@michaelrsweet michaelrsweet added priority-low and removed investigating Investigating the issue labels Apr 16, 2018
@foutrelis
Copy link

Your short-term workaround in CUPS sounds good. FWIW the exact log message is:

http_auth.cc(47)] Unable to create AuthHandler. Status: net::ERR_INVALID_RESPONSE Challenge: Basic realm="CUPS", Local

I'll try to dig into Chromium to see where the issue might be and/or create an upstream report about this.

@foutrelis
Copy link

Further investigation reveals that Chromium requires values for each field in the WWW-Authenticate header. RFC 7235 seems to agree with Chromium's behavior, I think because otherwise we can't tell if it's a new auth scheme or another auth parameter.

In this case, the "Local" parameter doesn't have a value. If this parameter is specific to CUPS, would it be possible to add a dummy value to it?

@michaelrsweet
Copy link
Collaborator

OK, according to RFC 7235 (which defines the syntax of the WWW-Authenticate header values) auth parameters are optional - the specific ABNF is:

challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
auth-scheme = token
auth-param  = token BWS "=" BWS ( token / quoted-string )
token68     = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="

WRT the CUPS-specific "Local" authentication scheme, it has one parameter ("trc" for "try root certificate") but we currently only add it if we want the client to try authenticating as root.

There is also the CUPS-specific "PeerCred" authentication scheme that is used over domain sockets.

@foutrelis
Copy link

You're right! My bad for not understanding Login is an authentication scheme and not a parameter.

Looking at net/http/http_auth.cc and HttpAuthChallengeTokenizer::Init, Chromium appears to accept multiple challenges but requires each of them to be in a separate WWW-Authenticate header. In other words, it rejects WWW-Authenticate headers with multiple challenges.

So a workaround in CUPS might be to issue a separate WWW-Authenticate: Login header. Would that work within CUPS?

@michaelrsweet
Copy link
Collaborator

It would mean separating WWW-Authenticate and all other headers using this syntax into multiple lines, which is tedious and should be totally unnecessary - after all, this functionality has been part of HTTP since RFC 2068 (the original HTTP/1.1 specification).

I will look at the options, but the least invasive option is to detect when Chrome is in use and simply omit the Local scheme.

michaelrsweet added a commit that referenced this issue Apr 16, 2018
@michaelrsweet
- Added a workaround for certain web browsers that do not support mul…
4feb1fe 
…tiple

  authentication schemes in a single response header (Issue #5289)
michaelrsweet added a commit that referenced this issue Apr 16, 2018
@michaelrsweet
Added a workaround for certain web browsers that do not support multi…
2390f1d 
…ple authentication schemes in a single response header (Issue #5289)
@michaelrsweet
Copy link
Collaborator

[master 4feb1fe] - Added a workaround for certain web browsers that do not support multiple authentication schemes in a single response header (Issue #5289)

[branch-2.2 2390f1d] Added a workaround for certain web browsers that do not support multiple authentication schemes in a single response header (Issue #5289)

@foutrelis
Copy link

Thanks for the fix! Please note the comment I added to commit 2390f1d (it appears to be incomplete).

Random fact: Chromium would also accept Basic realm="CUPS", Local realm="CUPS" apparently. I think it parses Local realm as a parameter with the value CUPS. Certainly nothing to rely on, and no reason to pollute the header with extra parameters just to trick Chromium into accepting it. Your fix seems much more robust.

michaelrsweet added a commit that referenced this issue Apr 16, 2018
@michaelrsweet
Try again to mirror fix (Issue #5289)
bb10add
@michaelrsweet
Copy link
Collaborator

[branch-2.2 bb10add] Try again to mirror fix (Issue #5289)

Yeah, I'd prefer to not add parameters that don't actually exist for the Local scheme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michaelrsweet michaelrsweet

Labels
priority-low
Projects
None yet
Milestone
CUPS 2.2.x Updates
Development

No branches or pull requests
4 participants
@foutrelis @michaelrsweet @Chais @ajacoutot