Is REST API in fact protected with Basic Authentication


#1

Hi,

The Couchbase 4.0 documentation states:

The Couchbase Server REST API, web console user interface, and command line utilities all use HTTP basic authentication.

Nevertheless, I can request /pools/default/buckets/[bucket_name]/stats data without providing any credentials.

Did I misunderstand something, how it suppose to work?
I use Couchbase CE 4.0.


Cbrecovery error: unable to access REST API
#2

Hello @dmitryb,

I suspect the bucket that is being used is not password protected as a result the stats for it are not protected. Once the bucket has a password then the stats for it can only be accessed via an authenticated user.

Here is an example of trying to access the stats for a password protect bucket, as expected a 401 error is returned.

$ curl -v http://localhost:8091/pools/default/buckets/test-bucket/stats
*   Trying ::1...
* connect to ::1 port 8091 failed: Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8091 (#0)
> GET /pools/default/buckets/test-bucket/stats HTTP/1.1
> Host: localhost:8091
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Basic realm="Couchbase Server Admin / REST"
< Server: Couchbase Server
< Pragma: no-cache
< Date: Wed, 29 Jun 2016 19:08:20 GMT
< Content-Length: 0
< Cache-Control: no-cache
< 
* Connection #0 to host localhost left intact

In a production environment we strong recommend that a bucket is always password protected. It is also worth mentioning that bucket configuration cannot be changed without being authenticated whether the bucket is password protected or not.


#3

Thank you for your reply, @pvarley!

You’re absolutely right the bucket is not password protected. I didn’t know that choosing a dedicated port for a bucket affects REST API authentication and I don’t remember seeing anything like that mentioned in the documentation either. I’d be happy to protect my bucket with a password, but strangely enough buckets with dedicated ports are auth-less, why is it so? I mean I just want to use a different port, not the standard one, why can’t the bucket still be password protected?

OK, but then why GET /pools/nodes also doesn’t require authentication, this path has nothing to do with the bucket already, is’t it?


#4

The dedicated port is misleading and I suspect most people do not understand what it does. When a dedicated port is selected a new Moix process is created on all the nodes that listens on that the port specified. Moxi is a proxy that allows legacy memcached clients to connection to Couchbase Server. If the application is using a Couchbase SDK then it will always communicate over port 11210 even if a “dedicated” port is selected. Pretty confusing I know!

This means that different ports cannot be used for different buckets when using a Couchbase Smart SDK and even with dedicated port selected the bucket is still accessible via port 11210 without a password. It’s possible to change the default port of 11210 but that will affect all buckets.

Again this follows the same rules as above when there is a non password protected bucket, I believe the reason in this case is to support older Couchbase SDKs that rely on this endpoint when communicating to the cluster.

There is a defect about explaining the true meaning of dedicated port but I’m on my phone and can’t find it right now.


#5

Yes, all these implications of choosing a dedicated port for the bucket are indeed confusing and should be better explained in the documentation I believe.
Especially the fact that not password protected buckets make the REST API unprotected as well or at least some of it’s endpoints. I would never guessed that, particularly because we authenticate in REST API with Administrator or read-only user credentials, which from the first sight has nothing to do with the bucket password…

I have just one more question about bucket dedicated port if you can answer.
I’m actually using a memcached client to operate the data in Couchbase, so I guess running Moxi process is what I need for now. But say I’m ready to switch using a smart client, then I can set a password for my bucket, but for that I’ll have to use the standard port option and this port is already used by a running memcached process on the same server. So the only way for me to solve this is to configure memcached to run on a different port or is there anything I can do on the Couchbase side to don’t use 11211 port? In the end, I won’t need Moxi service anymore when I switch to using a smart client, right?