-
Notifications
You must be signed in to change notification settings - Fork 68
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
Conversation
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>:
.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
No description provided.