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
Something that has occurred multiple times now is that users manually modify and/or create secrets in a format that can't be read by FTL (ie. not JSON). This is not surprising, as the values are relatively human readable, eg. a password might be "Deau34dWKWLCMWE8ymCN", however if the human edited value isn't JSON encoded correctly, FTL will fail to decode it.
I think we should add a comment to values, and obfuscate them so it's not trivial to edit them. eg. the above might be:
# This secret is managed by "ftl secret set", DO NOT MODIFY
IkRlYXUzNGRXS1dMQ01XRTh5bUNOIg==
Ideally this would not be per-provider, but generically applied. This might be fairly straightforward, if the resolver does this encoding, and the providers just store/retrieve the raw bytes.
The text was updated successfully, but these errors were encountered:
Something that has occurred multiple times now is that users manually modify and/or create secrets in a format that can't be read by FTL (ie. not JSON). This is not surprising, as the values are relatively human readable, eg. a password might be
"Deau34dWKWLCMWE8ymCN"
, however if the human edited value isn't JSON encoded correctly, FTL will fail to decode it.I think we should add a comment to values, and obfuscate them so it's not trivial to edit them. eg. the above might be:
Ideally this would not be per-provider, but generically applied. This might be fairly straightforward, if the resolver does this encoding, and the providers just store/retrieve the raw bytes.
The text was updated successfully, but these errors were encountered: