kio_http: HTTP body of 401 response not shown when SPNEGO authentication fails

[Trogel]

If an HTTP server responds with the "401 Unauthorized" status code and requests SPNEGO authentication with the response-header line "WWW-Authenticate: Negotiate", but kio_http fails to respond to the challenge, Konqueror shows a built-in error page saying "Authorization failed". Instead I'd expect to see the entity body of the server's 401 response.

The server I'm requesting actually sends an HTML page with a login form, but also allows for SPNEGO authentication (RFC 4559). Therefore it sends the login page with the "401 Unauthorized" status code and the response-header line "WWW-Authenticate: Negotiate". If the client can respond with appropriate authentication data, it will retry the HTTP request with an "Authorization" header. But if it cannot, it should show the entity body of the server's 401 response to the user so that he can manually log in. (I might be wrong, but this is my understanding of RFC 2616, section 10.4, "Client Error 4xx", where it says "User agents SHOULD display any included entity to the user." And that is what at least Firefox and probably other browsers currently do.)

However, if kio_http cannot respond to the server's SPNEGO request, it displays a built-in error page. So, Konqueror does not show the server's login form and the user cannot log in manually.

Reproduced on
- kubuntu trusty (14.04) with kdelibs5-plugins 4:4.13.3-0ubuntu0.1 and
- kubuntu utopic (14.10) with kdelibs5-plugins 4:4.14.1-0ubuntu1.

It took me a while to understand how this works, but now the fix appears to be quite simple. In certain places where kio_http detects an error, it calls sendErrorPageNotification() to check whether it should show the HTTP body of the server's response or a built-in error page. But this check does not happen when the last attempt to generate an "Authorization" response to the server's authentication request failed. Therefore it always shows the built-in error page in such cases.

As a patch (see attachment) to source package kde4libs-4.14.1 I added such check to kioslave/http/http.cpp and installed the modified package kdelibs5-plugins_4.14.1-0ubuntu1_amd64.deb. For me it works as desired, i.e. Konqueror now shows the login form. However, I cannot test this with a working SPNEGO environment or such.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "kde4libs-4.14.1-show-body-after-failed-auth.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Trogel (trogel)]

Also reproduced on xubuntu vivid (15.04) with kdelibs5-plugins 4:4.14.6-4~ubuntu3.1 and adjusted the patch.

[Trogel-3 (trogel-3)]

If an HTTP server responds with the "401 Unauthorized" status code and requests SPNEGO authentication with the response-header line "WWW-Authenticate: Negotiate", but kio_http fails to respond to the challenge, Konqueror shows a built-in error page saying "Authorization failed". Instead I'd expect to see the entity body of the server's 401 response.

Reproducible: Always

Steps to Reproduce:
1. Start Konqueror (or rekonq).
2. Enter the URL of a server that responds with the status code "401 Unauthorized" and the header "WWW-Authenticate: Negotiate", where kio cannot respond to the challenge.

Actual Results:
The browser shows a built-in error page saying "Authorization failed".

Expected Results:
The browser should show show the entity body of the server's 401 response.

The server I'm requesting actually sends an HTML page with a login form, but also allows for SPNEGO authentication (RFC 4559). Therefore it sends the login page with the "401 Unauthorized" status code and the response-header line "WWW-Authenticate: Negotiate". If the client can respond with appropriate authentication data, it will retry the HTTP request with an "Authorization" header. But if it cannot, it should show the entity body of the server's 401 response to the user so that he can log in manually. (I might be wrong, but this is my understanding of RFC 2616, section 10.4, "Client Error 4xx", where it says "User agents SHOULD display any included entity to the user." And that is what at least Firefox and probably other browsers currently do.)

However, if kio_http cannot respond to the server's SPNEGO request, it displays a built-in error page. So, Konqueror does not show the server's login form and the user cannot log in manually.

Reproduced on
- kubuntu trusty (14.04) with kdelibs5-plugins 4:4.13.3-0ubuntu0.1,
- kubuntu utopic (14.10) with kdelibs5-plugins 4:4.14.1-0ubuntu1, and
- xubuntu vivid (15.04) with kdelibs5-plugins 4:4.14.6-4~ubuntu3.1.

It took me a while to understand how this works, but now the fix appears to be quite simple. In certain places where kio_http detects an error, it calls sendErrorPageNotification() to check whether it should show the HTTP body of the server's response or a built-in error page. But this check does not happen when the last attempt to generate an "Authorization" response to the server's authentication request failed. Therefore it always shows the built-in error page in such cases.

As a patch to the Ubuntu source package kde4libs-4.14.6 I added such check to kioslave/http/http.cpp and installed the modified package kdelibs5-plugins_4.14.6-4~ubuntu3.1_amd64.deb. For me it works as desired, i.e. Konqueror now shows the login form and I can log in. However, I cannot test this with a working SPNEGO environment, since I have not such environment at hand.

(It seems in KDE's source repository the file is now located at ioslaves/http/http.cpp rather than kioslave/http/http.cpp as found in the Ubuntu source package. However, the bug seems to be still present in KDE's source. Just search for "Authorization failed".)

[Trogel-3 (trogel-3)]

Created attachment 94784
Patch as described above.

[Trogel-3 (trogel-3)]

Also reproduced on xubuntu wily (15.10) with kdelibs5-plugins 4:4.14.13-0ubuntu1. Patch still works.

[Justin Zobel (justin-zobel)]

Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!

[Trogel-3 (trogel-3)]

Thanks for your response! Unfortunately nowadays I cannot reproduce this issue. In the meantime I switched to the Firefox Browser, as more and more websites did not work properly with Konqueror. In addition the specific website that used SPNEGO that I had this issue with was shut down some years ago.

I am not familiar with this bug tracker and don't know the proper way for closing this report. Therefore I change the status back to REPORTED. Feel free to close this report as cancelled, irreproducible, or such.