Move ACP testing and extra non-defra specific logic to an other shared repo #2980
Labels
area/acp
Related to the acp (access control) system
area/testing
Related to any test or testing suite
code quality
Related to improving code quality
refactor
This issue specific to or requires *notable* refactoring of existing codebases and components
Comments
shahzadlone
added
area/testing
shahzadlone
added a commit
that referenced
this issue
Oct 2, 2024
## Relevant issue(s) Resolves #2762 ## Description This PR introduces the ability to make use of the `relation`s defined within a policy to create relationships between an actor and a document within a collection. For users sake, I have made the clients (http, and cli) not consume the `policyID` and `resource` name but instead a `docID` and `collection name`, since the collection will have the policy and resource information available we can fetch that and make lives easier for the users. This PR also makes use of the `manages` feature we have had in our policy. The manages essentially defines who can make the relationship manipulation requests. There are a lot of tests in this PR due to a lot of edge cases I wanted to have tested specific to `manger`, and ensuring `write` and `read` permissions don't leak (i.e. are accidently granted). ## CLI Demo The following lets the target actor be able to now read the private document: ```bash defradb client acp relationship add \ --collection Users \ --docID bae-ff3ceb1c-b5c0-5e86-a024-dd1b16a4261c \ --relation reader \ --actor did:key:z7r8os2G88XXBNBTLj3kFR5rzUJ4VAesbX7PgsA68ak9B5RYcXF5EZEmjRzzinZndPSSwujXb4XKHG6vmKEFG6ZfsfcQn \ --identity e3b722906ee4e56368f581cd8b18ab0f48af1ea53e635e3f7b8acd076676f6ac ``` Result: ```json { "ExistedAlready": false // <-------------- Indicates a new relationship was formed } ``` ### Future (out-of-scope of this PR): - Most of write tests will split into `delete` and `update` in #2905 - Ability to revoke or delete relation coming in #2906 - Decide on the `can't write if no read permission` in #2992 - Move acp logic to a shared repo: #2980 ## How has this been tested? - Integration tests Specify the platform(s) on which this was tested: - Manjaro WSL2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We decided that this repo should contain only defradb specific testing logic, this decision was a result of having some blurry lines where a lot of tests are being introduced where the are mainly testing acp components, logic, and edge cases rather than only defradb specific cases.
There are some components of defradb specific acp functionality (DPI validation, linking policy to a collection, and etc.) that should still be tested in defradb repo. Inaddition defradb should still contain all the basic tests for all acp clients to ensure they are integrated correctly.
The local acp implementation, sourcehub client logic should all be moved to the
shared repo.The sourcehub acp can continue to satisfy the same interfaces.
The
shared repowill have all different types oflocal acp clients(if there are more) and non-local ones.DefraDB will have one bridge per every acp type (ucan, or sourcehub for example), which will wrap a local version of that acp if there is one (like we already do for sourcehub).
So in the end this repo will contain:
Basic defradb specific acp logic
Basic testing for all acp clients to ensure they integrate correctly
The text was updated successfully, but these errors were encountered: