Keep stored secrets when a save carries the redaction sentinel
What happens to an operator
Open Settings, change any field, save. The instance API key and the SSL certificate password are both gone, replaced by the literal string REDACTED. The save reports success and the page redraws as normal, so there is nothing to notice at the time.
It sticks. The value is on disk in config.json, so a restart does not help, and a later save from a session that is not affected writes the placeholder again rather than repairing it. From the session that caused it there is no way back at all: RequireApiKeyManagementAccess turns that same caller away from both GET apikey and POST apikey/regenerate, so the key control on the screen comes up empty and a regenerate is refused with a 403 (listenarr.api/Attributes/RequireApiKeyManagementAccessAttribute.cs:49-81). Recovery means reaching the instance some other way, either regenerating from a session that gate does allow or putting the old value back into config.json by hand. Regenerating is the easier of the two but it rotates the key, so anything already configured with the old one has to be updated.
Not every caller hits this. It needs a request that HttpSecurityRequestUtils.ShouldRedactSecretsForCaller answers true for, which is a remote address the helper does not treat as private or loopback, on a request that is not already an authenticated admin or API-key principal (listenarr.api/Security/SecurityRequestHttpContextExtensions.cs:67). The plainest way to reach it is an instance with the login screen off, opened from an address outside the private ranges: a directly exposed instance, or one behind a proxy configured to forward the real client address. With the login screen off, RequireAdminOrApiKeyAttribute lets the request through, and nothing else stands between the browser and the save.
Why it happens
The settings screen fetches the startup config when it mounts and posts the same document ba...
Automated Canary build