Hi Austin Gebauer we have plans within the SDK to add a HTTP client, which will allow users to specify things like the URL path, body etc... and the SDK will handle routing and all those details. The timeframe for this isn't specified at the moment and it will initially be added at volatile API stability but it should cover this sort of usecase where you want to do something that the SDK doesn't specifically support.

Austin Gebauer given that gocb would be really just routing an HTTP request, could you approach this outside the SDK at the moment? There may be something I'm not considering here, as the SDK won't be doing anything particularly other than sending an HTTP request. Thanks!

Matt Ingenthron - We could definitely craft the HTTP request ourselves, but we'd prefer to use the Go SDK. I should mention that we aren't actually looking for the level of flexibility that Charles Dixon mentioned around specifying URL path, body, etc. We're looking for a way to change a user password with a less permissive role. It seems that using the changePassword API is the only way we can accomplish this. It would be great if the Go SDK had a native method for doing so, similar to the other user management functions (e.g., UpsertUser).

Context is that we (HashiCorp) have customers who want to use Vault to manage Couchbase users/credentials via https://www.vaultproject.io/docs/secrets/databases/couchbase. They don't want to give Vault a credential with the "full_admin" role in order to change the password of a user.

I appreciate the response!

Thanks Austin Gebauer. Just to give you some background behind our thoughts…

With the various management APIs to Couchbase Server, we've always aimed in the SDKs to implement the 20% of the API that has 80% of the use cases covered. While none of these are difficult, there is not (currently) a way to generate the management API from specifications and in practice the cluster's API can change even in dot-micro releases.

That's why, to cover the other cases, we were looking into adding a less-discoverable/less-specific API that is completely flexible and lets the SDK do the routing of the request.

I totally get the context and we've heard the same request.

One other question, just to validate, you're looking for a way for a 'user' to change their own password, not looking for a new role for password management of an arbitrary user. Correct? If it's the latter, we'd need another issue.

Hi Austin Gebauer we're planning on adding a ChangePassword function to the user manager which will change the password for the user authenticated when setting up the SDK instance. This means that the SDK instance will effectively become invalidated after calling the function, as auth will start to fail due to the authenticator being immutable. This just means that SDK will need to  be restarted with the new password. Does this work for you?

Matt Ingenthron - Thanks for the details! That all makes good sense.  For your last question, you're correct that we want the former (a way for a 'user' to change their own password). 

Charles Dixon - That sounds like exactly what we need. We're set up to invalidate the SDK instance on reconfiguration. Thanks for asking.

I'll keep an eye on this and see when we can get it integrated into Vault. Thanks, all!

FYI, created Epic CBD-4876 (so we can implement this across all SDKs per request from Arun Vijayraghavan) and moved this issue into the epic for tracking purposes.