Bug 804661 - rubygem-thin server does not respond correctly with 401, missing WWW-Authenticate header
rubygem-thin server does not respond correctly with 401, missing WWW-Authenti...
Status: NEW
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Angus Thomas
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2012-03-19 10:26 EDT by Brad P. Crochet
Modified: 2012-10-25 04:25 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for Katello to set WWW-Authentication header in case no credentials provided (1.49 KB, patch)
2012-05-04 10:48 EDT, Ivan Necas
no flags Details | Diff

  None (edit)
Description Brad P. Crochet 2012-03-19 10:26:49 EDT
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.


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):

How reproducible:

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.
Comment 1 Hugh Brock 2012-03-19 13:37:38 EDT
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?
Comment 2 Jeff Weiss 2012-03-19 13:57:58 EDT
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.
Comment 3 Jeff Weiss 2012-03-19 14:00:20 EDT
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.
Comment 4 Hugh Brock 2012-03-23 08:43:49 EDT
Mike, can you comment on this RC blocker please?
Comment 6 Hugh Brock 2012-04-04 11:05:32 EDT
Pushing to 1.1.
Comment 7 Ivan Necas 2012-05-04 10:48:31 EDT
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.
Comment 9 Lukas Zapletal 2012-10-25 04:25:46 EDT
I believe this was fixed in SE with https://bugzilla.redhat.com/show_bug.cgi?id=817946

Note You need to log in before you can comment on or make changes to this bug.