Reuse cluster connection objects but only for authorized users

[ritesh089]

The couchbase provider for wasmcloud now stores a connection object per link in the map. While this prevents link's from overwriting each other's connection objects, we may result in a lot of duplicates.

We will need to find a way to prevent duplicate connection object . A duplicate connection object is created when more than one connection object (cluster) has all the same properties: connection-string, bucketname, scope, collection, username, password.

Proposed solution 1 : We could maintain a hash of the above properties along with the connection object in the map . On a new link, we fetch the connection object from the map using the source id. If found, we compare the hash values . If they match , we dont add a new entry to the map . If they dont match, we create a new entry in the map . Now the Map key will need to be updated to include a suffix with the source id. Value of the suffix is TBD.

Solution 2 : Couchbase SDK to be updated to include the option to perform authorization at a more granular level . Eg: at a collection level or bucket level . This will reduce the overhead of having to fetch the cluster map on every link and still authorize again while reusing the existing clouchbase cluster object.

[vados-cosmonic]

Proposed solution 1 should have at least two benefits:

• Connection re-use (identical connection details could be used to de-duplicate, if sharing is reasonable)
• Security

As far as the improvement in security -- at present if the same component connects twice, but should be authorized differently/use different authentication for the connection, then the same connection is made available.

With proposed solution 1, we would effectively index by the Source ID and effectively the hash of the configuration object, to prevent this kind of overlap.

@ritesh089 just to make sure I was understanding right -- in this case we have a single webassembly component which needs to use different connection authentication levels, correct?

If we could split the component they would have separate source IDs and not overlap in this way.

[ingenthr]

@chvck I think we should automagically dereference to the same connection from the same process if the bucket and credentials precisely match. Am I correct for that here, or is Golang a bit different than our other SDKs?

cc/ @brett19

(aside: I know only enough about how this executes in WASM/WASI to be dangerous, so I'll be glad to be corrected if it's different)

[chvck]

I think we should automagically dereference to the same connection from the same process if the bucket and credentials precisely match. Am I correct for that here, or is Golang a bit different than our other SDKs?

In Go if the same Cluster object is used for opening buckets then calling cluster.Bucket multiple times with the same bucket name will reuse the existing "agent" for that bucket name under the hood - that is basically the same set of connections. The bucket name (sort of) gets baked into each connection at connect time. At present to open the same bucket twice but with different credentials would require two Cluster instances. Scopes and collections are specified at the request level on the wire rather than connection level so do not have the same overheads/considerations.