Private Datasets: Checking dataset accessibility in kamu
subcommands (multi-tenant workspace)
#1055
Labels
enhancement
New feature or request
good first issue
Good for newcomers
rust
Pull requests that update Rust code
Preamble
We have implemented dataset availability checks in API (HTTP, GQL), so, for example, we cannot access another user's private datasets.
However, if we work locally with a workspace (multi-tenant) using
kamu
CLI, some of the checks are missing.The purpose of this ticket is to achieve consistency/parity with the API when accessing other users' datasets.
Points of technical interest/patterns
In general, it is possible to identify generalized patterns (P) for obtaining datasets that are currently in use:
P1) Addressing a single dataset:
P2) Obtaining datasets by pattern:
P3) Retrieving all datasets, followed by checking by arbitrary conditions
Possible approaches when implementing checks:
A1) Straightforward: we can apply
DatasetActionAuthorizer
to the receiveddataset_handle
(s), which will sift through the datasets, identifying only those to which the current user has access.Optionally, the sifting can be hidden inside the filtering utilities:
kamu::utils::datasets_filtering::*
.A2) Continue the trend of extracting (generalizing) use cases that may absorb the access checks.
As a reference implementation, it is suggested to check:
ViewDatasetUseCase, EditDatasetUseCase
. In some cases, these use cases will be enough to use.The choice of proportion between the two approaches (A1, A2) is determined on the spot.
The text was updated successfully, but these errors were encountered: