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

Bug #1392709 reported by Trogel on 2014-11-14
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kdelibs
New
Medium
kde4libs (Ubuntu)
Undecided
Unassigned

Bug Description

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.

Trogel (trogel) wrote :
Trogel (trogel) on 2014-11-14
tags: added: kubuntu spnego

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.]

tags: added: patch
Trogel (trogel) wrote :

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

tags: added: xubuntu

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".)

Created attachment 94784
Patch as described above.

Changed in kdelibs:
importance: Unknown → Medium
status: Unknown → New

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.