fix(configuration): treat empty secret as explicit clear - #7756
Conversation
When a user clears a password field in the UI and saves, the empty
string is persisted to the data source options as-is. Downstream SDKs
(e.g. boto3) then receive an explicit empty credential instead of
falling back to the default credential chain, and authentication fails
with empty keys (observed with the Athena data source's
aws_secret_key).
Distinguish the placeholder ("--------", meaning "no change") from an
empty string ("explicit clear") and drop the latter from the stored
options.
Greptile SummaryThis PR distinguishes unchanged secret placeholders from explicitly cleared secrets and adds a unit test for removing cleared values.
Confidence Score: 4/5This PR should not merge until clearing a schema-required secret is rejected rather than persisted as an invalid configuration. Empty required secrets pass input validation before being deleted, and the resulting invalid options are committed without a second validation step. Files Needing Attention: redash/utils/configuration.py
|
| Filename | Overview |
|---|---|
| redash/utils/configuration.py | Adds explicit secret-clearing behavior, but performs deletion after validation and can persist a configuration missing a required secret. |
| tests/test_configuration.py | Covers removal of an optional emptied secret but not rejection of an emptied required secret. |
Reviews (1): Last reviewed commit: "Merge branch 'master' into fix/empty-sec..." | Re-trigger Greptile
| elif k in secrets and v == "": | ||
| # An empty secret means the user explicitly cleared the field; drop it. | ||
| continue | ||
| else: |
There was a problem hiding this comment.
Required secrets bypass validation
When Athena runs with ATHENA_OPTIONAL_CREDENTIALS=false and ATHENA_ASSUME_ROLE=false, an empty aws_secret_key satisfies the required-field validation and is then removed before persistence, leaving the stored configuration invalid and causing subsequent queries to fail authentication instead of rejecting the update.
What type of PR is this?
Description
When a user clears a password field in the UI and saves, the empty string is persisted to the data source options as-is. Downstream SDKs (e.g. boto3) then receive an explicit empty credential instead of falling back to the default credential chain, and authentication fails with empty keys (observed with the Athena data source's aws_secret_key).
Distinguish the placeholder ("--------", meaning "no change") from an empty string ("explicit clear") and drop the latter from the stored options.
How is this tested?
Related Tickets & Documents
N/A
Mobile & Desktop Screenshots/Recordings (if there are UI changes)
N/A - backend-only change.