Skip to content

Keep locked API access controls usable - #292

Open
webdevtodayjason wants to merge 1 commit into
mainfrom
fable/issue-262
Open

webdevtodayjason wants to merge 1 commit into
mainfrom
fable/issue-262

Conversation

@webdevtodayjason

@webdevtodayjason webdevtodayjason commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #262

Problem

The API access panel could trust cached signed-in browser state even when /api/auth/status said the current request was unauthenticated. That stale state exposed Stop requiring a key, but the server correctly rejected the click.

Decision

Treat the server authenticated flag as the authority for the panel state, the disable control, and whether the key-entry details start open. Replace the source-text assertion with a Node behavior test that renders locked, stale-user, and authenticated states against the real app.js method.

Proof

  • pytest -q tests/test_auth_usable.py: 19 passed
  • ruff check .: all checks passed
  • Full isolated suite: 3240 passed, 2 skipped, 1 xfailed. Two unrelated failures and one setup error remained under concurrent host pressure: the download guard saw only 1.2 GB free, pytest temporary directory numbering collided with other runs, and the hostname cache timing test exceeded its one-second wait.

Changelog: Fix the API access panel so locked browsers only get usable key-entry controls.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

API access page offers "Stop requiring a key" while the browser has no key

1 participant