You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when the outputs are preconfigured, we set the secrets as cleartext strings, and also provide the frontend with those cleartext strings.
To handle secrets, we could proceed as follows:
The configs in the cbc.yaml, if they are a secret, should be identified with: secret: true (or something like that)
In core, we could handle it like this:
All config keys, that are secrets, will be treated as booleans (if core provides a default value for the key (e.g. provided over ENV variable DEFAULT_CB_CONFIG_PG_PASS or DEFAULT_CB_CONFIG_S3_ACCESS_KEY) or will be set as null by default.
This lets the user to either check a box -> "use default" in the frontend, or to set a string manually.
On create, we then know, if the user wants to take the default value we provide in the backend (if we provide one), or we can hash the string that he sent us and then insert it in the database.
We will never send any secrets to the frontend
The dag translator would need to decrypt the secrets gained from the db
The frontend, needs a "new" input component where the user can either tick a checkbox, or provide a string
The response model of compute-block information & get compute block must be refactored (frontend & backend) -> We must know if a secret key has a default, or if the user HAS TO provide a value
How would we handle autoconfiguration of inputs? -> TODO
Currently, when the outputs are preconfigured, we set the secrets as cleartext strings, and also provide the frontend with those cleartext strings.
To handle secrets, we could proceed as follows:
cbc.yaml, if they are a secret, should be identified with:secret: true(or something like that)In core, we could handle it like this:
All config keys, that are secrets, will be treated as
booleans(if core provides a default value for the key (e.g. provided over ENV variableDEFAULT_CB_CONFIG_PG_PASSorDEFAULT_CB_CONFIG_S3_ACCESS_KEY) or will be set as null by default.This lets the user to either check a box -> "use default" in the frontend, or to set a string manually.
On create, we then know, if the user wants to take the default value we provide in the backend (if we provide one), or we can hash the string that he sent us and then insert it in the database.
We will never send any secrets to the frontend
The dag translator would need to decrypt the secrets gained from the db
This Issue requires changes at a fow location:
cbc.yamlnull values in configs & envs should be typed scystream-sdk#19