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.
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.
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?
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.
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?