Listenarrs/Listenarr v1.0.4-canary

Canary 1.0.4

on GitHub

Summary

The Admin Account Management subpanel in Settings → Authentication was gated by v-if="authEnabledComputed", which meant the username/password inputs were invisible whenever the Enable login screen toggle was off. Combined with the toggle reflecting the server-side AuthenticationRequired value from config.json, this produced a hard lockout for new installs:

1. Operator edits config/config.json to set AuthenticationRequired: "true" (or uses the UI toggle and clicks Save — which writes the same value).
2. Login screen activates on the next request.
3. No admin user has been provisioned, because the only UI affordance to do so was inside the gated section that doesn't render until auth is already on.
4. Every login attempt fails. There is no UI path to recover; the operator has to either edit config.json back to false and restart, or curl the /api/v1/configuration/settings endpoint with the API key + a JSON body containing AdminUsername / AdminPassword — which bypasses CSRF and creates the user — neither of which a user should be expected to know.

Fix

Drop the v-if gate. The credential inputs now render whenever the Authentication section is on screen, regardless of the login-screen toggle state. Operators can configure (or pre-configure) admin credentials before, during, or after enabling auth — eliminating the lockout window.

Help text and the password placeholder were updated to reflect the actual backend semantics:

• The fields are accepted at any time and are persisted with Save Settings.
• Both fields must be non-empty for ConfigurationService to create/update the admin user (see listenarr.application/Common/ConfigurationService.cs ~line 245).
• Leaving the password blank is the explicit "keep existing" path.

Test plan

• npm run type-check — clean
• npx vitest run AuthenticationSection.spec.ts — 4 / 4 passing
• New regression test added (`renders the a...

Automated Canary build

• Version: 1.0.4
• Commit: 8bb9458
• Original PR: #623