Sync Gateway: (pseudo)random 401 "Invalid login" with BasicAuth


#1

Hi Sync Gateway users,

I am accessing the Sync Gateway through the Public REST API, authenticating with BasicAuth, and some of the requests are returned with 401 errors.

To be more precise, my datalogger sends a POST request (new document) to /{db}/ once per hour. The pattern is always the same: one request is accepted, then the next hour is refused, then next hour accepted again, etc, and it alternates strictly… I noticed this alternation if I increase the interval to 3 hours, also. But if I decrease the interval to a few minutes, all authentications go through and requests do proceed…

I got around it by sending a dummy GET /{db}/ request just before doing the actual POST request, so the dummy request is at the front line and gets the refusals, and the POST request goes through. It usually works, but on some occasions both requests got refused with a 401 (!).

Is there anything in the way Sync Gateway handles BasicAuth that could explain this behaviour?

I am using Sync Gateway community edition 1.2.1-4 and had the same issues with 1.2.0-79

Here is an extract captured with tcpdump on port 4984:

GET /default/ HTTP/1.1
Host: XX.XX.XX.XX:4984
Authorization: Basic YWRtaW46YWRtaW4=

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Server: Couchbase Sync Gateway/1.2.1
Www-Authenticate: Basic realm="Couchbase Sync Gateway"
Date: Thu, 19 May 2016 11:38:05 GMT
Content-Length: 49

{“error”:“Unauthorized”,“reason”:“Invalid login”}

POST /default/ HTTP/1.1
Host: XX.XX.XX.XX:4984
Authorization: Basic YWRtaW46YWRtaW4=
Content-Length: 105

{“type”:“sensor”,“id”:“123”,“time”:1463657910,“data”:[{“t”:1463654251,“d”:449},{“t”:1463656056,“d”:449}]}

HTTP/1.1 200 OK
Content-Length: 94
Content-Type: application/json
Etag: "1-7e8aabb8bbf760fc2a915d098641b496"
Location: 77de55209876ad610dde0afe94944605
Server: Couchbase Sync Gateway/1.2.1
Date: Thu, 19 May 2016 11:38:35 GMT

{“id”:“77de55209876ad610dde0afe94944605”,“ok”:true,“rev”:“1-7e8aabb8bbf760fc2a915d098641b496”}

and the corresponding Sync Gateway log:

11:38:05.811756 2016-05-19T11:38:05.811Z HTTP auth failed for username="admin"
11:38:05.811789 2016-05-19T11:38:05.811Z HTTP: #214: GET /default/
11:38:05.811823 2016-05-19T11:38:05.811Z HTTP: #214: --> 401 Invalid login (0.2 ms)
11:38:35.232664 2016-05-19T11:38:35.232Z HTTP: #215: POST /default/ (as admin)
11:38:35.234878 2016-05-19T11:38:35.234Z HTTP+: #215: --> 200 (3.8 ms)

other example:

POST /default/ HTTP/1.1
Host: 52.16.49.121:4984
Authorization: Basic YWRtaW46YWRtaW4=
Content-Length: 105

{“type”:“sensor”,“id”:“123”,“time”:1463560059,“data”:[{“t”:1463556432,“d”:450},{“t”:1463558237,“d”:449}]}

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Server: Couchbase Sync Gateway/1.2.0
Www-Authenticate: Basic realm="Couchbase Sync Gateway"
Date: Wed, 18 May 2016 08:27:46 GMT
Content-Length: 49

{“error”:“Unauthorized”,“reason”:“Invalid login”}

POST /default/ HTTP/1.1
Host: 52.16.49.121:4984
Authorization: Basic YWRtaW46YWRtaW4=
Content-Length: 105

{“type”:“sensor”,“id”:“123”,“time”:1463563721,“data”:[{“t”:1463560093,“d”:449},{“t”:1463561898,“d”:450}]}

HTTP/1.1 200 OK
Content-Length: 94
Content-Type: application/json
Etag: "1-e02ebb784f9a46b99d6b024c1d29c7ec"
Location: 1403a87a6d0630e65c2484cd25f83394
Server: Couchbase Sync Gateway/1.2.0
Date: Wed, 18 May 2016 09:28:47 GMT

{“id”:“1403a87a6d0630e65c2484cd25f83394”,“ok”:true,“rev”:“1-e02ebb784f9a46b99d6b024c1d29c7ec”}

Any ideas?
Thanks!

Nico


#2

That’s really weird! I suggest you file a bug report on Github, since this definitely doesn’t look like a mistake on your part.


#3

Thanks for your answer jens.

I first thought the problem was on my client side, so this is why I looked at the packets with tcpdump, to make sure the requests are perfectly identical. Furthermore, there’s a Python/Flask script running on the same machine, and the same behaviour happens when the script sends a request to Sync Gateway’s public REST API with BasicAuth: first request is refused with 401, second is accepted.

I will file a bug report on Github, then.

Could this be related to another behaviour? When sending a GET /{db}/ request from my browser, but without authentication, the first request fails with {“error”:“Internal Server Error”,“reason”:“Internal error: EOF”}, but the second goes through with a 401 answer:

GET /test/ HTTP/1.1
Host: XX.XX.XX.XX:4984
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en
Accept-Encoding: gzip, deflate
Cookie: ui-auth-XX.XX.XX.XX%3A8091=786e39110c69441c4dbf6ba3823da774
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Server: Couchbase Sync Gateway/1.2.1
Date: Sat, 21 May 2016 16:05:33 GMT
Content-Length: 64

{“error”:“Internal Server Error”,“reason”:“Internal error: EOF”}

GET /test/ HTTP/1.1
Host: XX.XX.XX.XX:4984
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en
Accept-Encoding: gzip, deflate
Cookie: ui-auth-XX.XX.XX.XX%3A8091=786e39110c69441c4dbf6ba3823da774
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Server: Couchbase Sync Gateway/1.2.1
Www-Authenticate: Basic realm="Couchbase Sync Gateway"
Date: Sat, 21 May 2016 16:05:39 GMT
Content-Length: 50

{“error”:“Unauthorized”,“reason”:“Login required”}

Cheers!
Nico


#4

You should definitely file a bug report on the issue in that latest transcript. I don’t know if it’s related to the first problem. It might be, but it depends on exactly what’s causing that internal server error.