Skip to content

Fix: refuse a settings save before it writes anything - #39

Merged
SandObserver merged 1 commit into
mainfrom
fix/atomic-settings-save
Aug 12, 2026
Merged

SandObserver merged 1 commit into
mainfrom
fix/atomic-settings-save

Conversation

@SandObserver

Copy link
Copy Markdown
Owner

Summary

  • Add settingsSaveBlocker and clearsStoredPassword to admin-logic.js, with a BLOCK code pair so the catalog keys stay literal at the call site.
  • Move the auth-enable and password-strength checks ahead of the first request in saveServer, so a refused save leaves the server untouched instead of storing the title, description, host IP, Docker settings, log level and language first.
  • Take the pwStrength result as an argument rather than importing it into admin-logic.js, which is imported by tests that do not register the /js/ resolve hook.
  • Extract the /api/auth/check handling in loadSettings into syncAuthFromServer, and call it after a successful save, after a failure part way through the three writes, and after declining the password-clearing confirm.
  • Drop the hand-maintained _passwordSet, stored-password row and session-row updates from the save path, which now follow from the read-back.

Testing
All green. Added 10 tests for the blocker's rule order and the confirm rule.

Checklist

  • Stays within the project constraints: one container, no runtime dependencies, no build step (see CONTRIBUTING.md).
  • Tests added or updated for new logic, and the full suite, lint, and typechecks pass.
  • Docs updated if behavior or configuration changed.
  • CHANGELOG.md updated under Unreleased if the change is user-visible.

@SandObserver SandObserver added the bug Something isn't working label Aug 12, 2026
saveServer sent the config first and checked the password rules after, so a
refused save had already stored the title, description, host IP, Docker
settings, log level and language while reporting only the password problem.
The Password Protection switch was left showing a state the server had
rejected, with nothing to tell the two apart.

Move both rules ahead of the first request as settingsSaveBlocker, so a
refusal leaves the server exactly as it was, and name the confirm rule as
clearsStoredPassword. The strength result is passed in rather than imported:
admin-logic.js is imported by tests that do not map the served /js/ paths, and
one import there breaks all of them.

Read the security rows back from the server through syncAuthFromServer after a
save, after a failure part way through the three writes, and after declining
the password-clearing confirm, instead of inferring them from what was sent.
@SandObserver
SandObserver force-pushed the fix/atomic-settings-save branch from 37995ac to 37f4f0e Compare August 12, 2026 02:09
@SandObserver
SandObserver merged commit 0c8925d into main Aug 12, 2026
4 checks passed
@SandObserver
SandObserver deleted the fix/atomic-settings-save branch August 12, 2026 02:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant