Handle secrets in the UI

[sherifnada]

Tell us about the problem you're trying to solve

#1022 changed the airbyte API to obfuscate secrets in the top-level of a connector's config as described in #986 with the difference that only top-level secrets are handled. This issue concerns having the UI handle secrets in line with that change. Specifically:

• UI Read: When it receives from the API a field with the airbyte_secret flag set to true, it can act as normal, it just displays **********
• UI Update: This has some edge cases.
  • If user updates config but does not touch sensitive field, UI sends ********** (the exact same value sent by the API) to the API (which means it is a no op).
  • If user edits the secret field in any way then UI sends the updated value to the API. If the value is anything other than the exact obfuscated value sent by the API, the API regards this as an update.

[cgardens]

Per our discussion last week, it sounds like this will entail building a special UI component for secrets.

[jamakase]

@sherifnada I have 2 questions:

1. How are we going to handle a case, when user wants to set ********** as some secret?
2. airbyte_secret is not a standard json_schema key. Is there a way to use some default one?

[sherifnada]

@jamakase

How are we going to handle a case, when user wants to set ********** as some secret?

********** will not be allowed as a password value (it will be interpreted as a non-update)

airbyte_secret is not a standard json_schema key. Is there a way to use some default one?

it seems like writeOnly is the main (and maybe only?) applicable annotation here. But could we start off with airbyte_secret for the time being since all integrations currently use it? I can create an issue to use writeOnly if needed. What would be the upside of using writeOnly over a custom annotation?

[jamakase]

@sherifnada not quite a fan of an assumption that user will never use ********** as password. Isn't it better to use something rarer? It can be still once generated value, but something like 72AE25495A7981C40622D. Though not a strict requirement and I implement it as stated in this issue.

Currently, we use airbyte_secret. I was just interested if there is some other field we can use. If you think writeOnly fits and it is part of json spec: I would be glad to change, when we have time.