-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reuse cluster connection objects but only for authorized users #8
Comments
Proposed solution 1 should have at least two benefits:
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. |
@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) |
In Go if the same Cluster object is used for opening buckets then calling |
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.
The text was updated successfully, but these errors were encountered: