Skip to content

implement user define secret management api #112

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

Merged
merged 2 commits into from
Jan 28, 2025
Merged

Conversation

v9n
Copy link
Member

@v9n v9n commented Jan 27, 2025

No description provided.

Copy link
Member

@chrisli30 chrisli30 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!


**Secret Storage**
- currently org_id will always be _ because we haven't implemented it yet
- workflow_id will also be _ so we can search be prefix
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t quite get this line, - workflow_id will also be _ so we can search be prefix

Does this mean the search is not done at the workflow level, but only user level? I’m fine with that, but let’s clarify this comment.

Copy link
Member Author

@v9n v9n Jan 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean the search is not done at the workflow level, but only user level?

No, that is to help us search at any level we want. Regardless org or user id or workflow id.

We used https://github.com/dgraph-io/badger and we employee prefix search https://dgraph.io/docs/badger/get-started/#prefix-scans

We organize the key in this format (they are in schema.go btw)

secret:<org_id>::<workflow_id>:

When a thing is at user level, then workflow_id will be empty. we re-present it with _. Doing so will allow us to perform prefix scan of all user level secret by doing https://dgraph.io/docs/badger/get-started/#prefix-scans over secret:_:0x12345:_

To search all secret at workflow level we scan secret:_:0x12345:<workflow-id>.
To search all secret belong to an org we scan secret:<org-id>:.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh I see. Makes sense 👌

@@ -453,5 +453,323 @@ func TestTriggerCompletedTaskReturnError(t *testing.T) {
if err == nil || resultTrigger != nil {
t.Errorf("expect trigger error but succeed")
}
}

func TestCreateSecret(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently we don’t need to add the same tests in sdk, if unit tests are done here, but I don’t have good visibility what are covered in the unit tests.

For this module, let’s rely on these units for testing, but simple tests are still needed in the sdk, so I can look up the usage of the secrets sdk code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes will add unit test on sdk anyway. not because we want to test the AVS but we want to test that the SDK is sending data in the correct format and can retreive data.

@v9n v9n merged commit 3e9bec3 into main Jan 28, 2025
4 checks passed
@v9n v9n deleted the secret-management-api branch January 28, 2025 02:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants