Bug 353371 - HTTP body of 401 response not shown when SPNEGO authentication fails
Summary: HTTP body of 401 response not shown when SPNEGO authentication fails
Status: REPORTED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: HTTP (show other bugs)
Version: 5.48.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-30 13:19 UTC by trogel
Modified: 2022-12-23 08:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch as described above. (802 bytes, patch)
2015-09-30 13:21 UTC, trogel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description trogel 2015-09-30 13:19:00 UTC
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".)
Comment 1 trogel 2015-09-30 13:21:35 UTC
Created attachment 94784 [details]
Patch as described above.
Comment 2 trogel 2015-11-12 05:48:38 UTC
Also reproduced on xubuntu wily (15.10) with kdelibs5-plugins 4:4.14.13-0ubuntu1. Patch still works.
Comment 3 Justin Zobel 2022-12-23 00:28:21 UTC
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!
Comment 4 trogel 2022-12-23 08:21:46 UTC
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.