{"action":"created","issue":{"url":"https://api.github.com/repos/erikdoe/ccmenu/issues/11","labels_url":"https://api.github.com/repos/erikdoe/ccmenu/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/erikdoe/ccmenu/issues/11/comments","events_url":"https://api.github.com/repos/erikdoe/ccmenu/issues/11/events","html_url":"https://github.com/erikdoe/ccmenu/pull/11","id":54163645,"number":11,"title":"Populate basic auth header pre-401-challenge.","user":{"login":"drn","id":885841,"avatar_url":"https://avatars.githubusercontent.com/u/885841?v=3","gravatar_id":"","url":"https://api.github.com/users/drn","html_url":"https://github.com/drn","followers_url":"https://api.github.com/users/drn/followers","following_url":"https://api.github.com/users/drn/following{/other_user}","gists_url":"https://api.github.com/users/drn/gists{/gist_id}","starred_url":"https://api.github.com/users/drn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/drn/subscriptions","organizations_url":"https://api.github.com/users/drn/orgs","repos_url":"https://api.github.com/users/drn/repos","events_url":"https://api.github.com/users/drn/events{/privacy}","received_events_url":"https://api.github.com/users/drn/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-01-13T08:40:11Z","updated_at":"2015-01-20T19:12:19Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/erikdoe/ccmenu/pulls/11","html_url":"https://github.com/erikdoe/ccmenu/pull/11","diff_url":"https://github.com/erikdoe/ccmenu/pull/11.diff","patch_url":"https://github.com/erikdoe/ccmenu/pull/11.patch"},"body":"Fixes https://github.com/erikdoe/ccmenu/issues/9 (I ran into the same issue when trying to configure Jenkins)\r\n\r\nIf a CI server doesn't 401 and instead renders empty XML (e.g. Jenkins), the basic auth headers are never set. What this commit does is pre-populates the `Authorization` header anytime credentials are available.\r\n\r\nI didn't add tests because it's getting late, but the test suite passes with these changes in place."},"comment":{"url":"https://api.github.com/repos/erikdoe/ccmenu/issues/comments/70713197","html_url":"https://github.com/erikdoe/ccmenu/pull/11#issuecomment-70713197","issue_url":"https://api.github.com/repos/erikdoe/ccmenu/issues/11","id":70713197,"user":{"login":"erikdoe","id":954026,"avatar_url":"https://avatars.githubusercontent.com/u/954026?v=3","gravatar_id":"","url":"https://api.github.com/users/erikdoe","html_url":"https://github.com/erikdoe","followers_url":"https://api.github.com/users/erikdoe/followers","following_url":"https://api.github.com/users/erikdoe/following{/other_user}","gists_url":"https://api.github.com/users/erikdoe/gists{/gist_id}","starred_url":"https://api.github.com/users/erikdoe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/erikdoe/subscriptions","organizations_url":"https://api.github.com/users/erikdoe/orgs","repos_url":"https://api.github.com/users/erikdoe/repos","events_url":"https://api.github.com/users/erikdoe/events{/privacy}","received_events_url":"https://api.github.com/users/erikdoe/received_events","type":"User","site_admin":false},"created_at":"2015-01-20T19:12:19Z","updated_at":"2015-01-20T19:12:19Z","body":"The header that is added by this PR implements basic authentication. The way CCMenu uses the Apple libraries at the moment allows CCMenu to authenticate using basic or digest authentication. By accepting the PR as is I believe we'd lose the ability to do digest authentication. \r\n\r\nAlso, RFC2617 states that \"The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based upon that challenge.\" So, for servers that offer both digest and basic using basic would be against the spirit of RFC2617.\r\n\r\nAt the same time it seems that the app server is doing something unusual. It is odd that when trying to access a protected resource without authentication headers the server returns a 200 OK with an empty response. As far as I understand it should signal to the client that the resource is protected by responding with 401 Unauthorized, and, again quoting RFC2617, the \"response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.\"\r\n\r\nI am all for supporting \"bad\" servers for maximum compatibility. However, I don't think catering to such servers should be the default, especially when it has a negative overall effect."}}