Posting an empty JSON body seems to give valid session token/cookie?

Using the following curl request:

curl --location --request POST 'https://<public api url>/<database>/_session' \
     --header 'Accept: application/json' \
     --header 'Content-Type: application/json' \
     --data-raw '{ }'

We get a session cookie back. If I then use that cookie to attempt to read all documents, or create a new document etc, it seems I have full access to do so.

The GUEST user on the sync gateway is disabled.

Please advise.

The “users” block in the sync gateway config looks like the following:

"users": {
    "GUEST": {
        "name": "",
        "all_channels": null,
        "disabled": true

What channels are these documents in, and what’s in your sync function?

Generally write-access needs to be restrited with the sync function, depending on your application requirements. Checking for specific users/roles/channels for each given write of a document. You can also route documents into channels in here too for read-access control.

Read access is determined at document read time by the channels each document and user are in, primarily to allow dynamic channel grants.

I went and re-read your original post, and I think I see where you were going with the question now.
I misinterpreted for the original response above so ignore if not appliccable.

Let me dig around a bit and see what’s going on here to be getting a user session back when guest is disabled.

I’ve not been able to reproduce on my local development version of SG. I get back a 401 for a blank session request with a disabled guest user, but want to check some things in your environment:

Can you confirm whether you have a disabled guest user in your Couchbase bucket, and the version of Sync Gateway you’re running?

The guest doc shoud have this ID, and the body roughly looking like this:
ID: "_sync:user:"
Body: {"all_channels":{},"sequence":2,"disabled":true,"rolesSince":{}}

Version of the sync gateway is ==== Couchbase Sync Gateway/2.8.0(376;e2e7d42) EE ====
The document I think you’re asking about appears to be:


Also, the response I get to the above curl request is:

    "authentication_handlers": [
    "ok": true,
    "userCtx": {
        "channels": {
            "*": 3,
            "!": 1
        "name": null

OK, for some reason the guest user is not being disabled properly.
In my case, when I flip the guest disabled option from false to true, I get this log on SG startup showing the guest user document get updated:

Using default sync function 'channel(doc.channels)' for database "db1"
2021-01-25T16:45:17.185Z [INF] Auth: Saved principal w/ name:, seq: #4
2021-01-25T16:45:17.185Z [INF] Reset guest user to config
2021-01-25T16:45:17.185Z [INF] DCP: Received #4 ("_user/")
2021-01-25T16:45:17.185Z [DBG] Changes+: Notifying that "db1" changed (keys="{_sync:user:}") count=2

Which writes the “disabled”: true property to that user doc in the bucket.
And then any attempts to get a session fail:

2021-01-25T16:45:19.694Z [INF] HTTP:  #001: POST /db1/_session (as GUEST)
2021-01-25T16:45:19.694Z [INF] HTTP: #001:     --> 401 Invalid login  (0.5 ms)

Are there any similar logs on startup for you? For what it’s worth, your config looks correct.

We’ve rebuilt the servers and the config file is taking the updated GUEST settings. It appears that using the API and file can cause a conflict. Hoping this was a one time occurrence