Description of problem: The thin server does not respond correctly when a URI that requires authentication is requested, and authentication is not sent. According to HTTP 1.0/1.1 specs, a 401 MUST include WWW-Authenticate in the response. Since it does not include this header, it causes clients to fail that hit the URI first, and await the proper 401 in order to continue. Clients should not automatically send authentication in the first request, since credentials could potentially be sent in the clear. The WWW-Authenticate header is necessary to do a proper handshake. http://www.w3.org/Protocols/HTTP/1.0/spec.html#Code401 401 Unauthorized The request requires user authentication. The response must include a WWW-Authenticate header field (Section 10.16) containing a challenge applicable to the requested resource. The client may repeat the request with a suitable Authorization header field (Section 10.2). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user should be presented the entity that was given in the response, since that entity may include relevant diagnostic information. HTTP access authentication is explained in Section 11. Version-Release number of selected component (if applicable): rubygem-thin-1.2.11-3.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. curl -k -v https://a.conductor.host/conductor/api/images (OR) 2. curl -k -v https://a.katello.host/katello/api/consumers Actual results: Response without credentials: < HTTP/1.1 401 Unauthorized < Date: Mon, 19 Mar 2012 14:24:40 GMT < Server: thin 1.2.11 codename Bat-Shit Crazy < Cache-Control: no-cache < X-Runtime: 0.025463 < X-UA-Compatible: IE=Edge,chrome=1 < Content-Type: application/xml; charset=utf-8 < Set-Cookie: _session_id=d44a7aec303b80319644a5decc35ff5a; path=/; HttpOnly < Connection: close < Transfer-Encoding: chunked Expected results: Response without credentials MUST include WWW-Authenticate according to HTTP 1.0/1.1 spec.
Is this really a bug in Thin? If so it's too late to do anything about it for 1.0. If it's actually an app server or app bug, maybe we have scope to fix it. Could someone on the katello team please have a look?
It might be configurable from our end, I'll let dev comment on that. We have other clients, that seem to not mind this problem (RHSM, automation with curl, automation with apache HTTP client). I haven't watched the HTTP traffic enough to know if they just don't care about the missing header, or if they provide credentials on the first request. I am 90% sure it's the latter. So that seems like a simple workaround.
If it is a security issue to send auth on the first request, and RHSM is doing that, we may need to fix that also.
Mike, can you comment on this RC blocker please?
Pushing to 1.1.
Created attachment 582134 [details] Patch for Katello to set WWW-Authentication header in case no credentials provided I don't think it's a problem of thin itself. The itself application has to determine whether the credentials were sent or not. In Katello there is possibility to authenticate using client certificates as well. Warden is used for this purpose in Katello and it's quite easy to set the required header in case no credentials provided. See the patch.
I believe this was fixed in SE with https://bugzilla.redhat.com/show_bug.cgi?id=817946