fix(security): plain 401 for programmatic requests — no browser login dialog over background polls#6128
Merged
Merged
Conversation
… dialog over background polls An expired session answered EVERY request with 401 + WWW-Authenticate: Basic, so the BROWSER popped its native login dialog before any script saw the response. The generated Harmonia apps poll the inbox every 30 seconds, so an idle tab surfaced the dialog "out of nowhere" once the 8h session lapsed (or the server restarted). BasicSecurityConfig now registers an additional authentication entry point for programmatic requests - Sec-Fetch-Mode present and != navigate (every modern browser stamps fetch/XHR), with X-Requested-With: XMLHttpRequest as the legacy fallback - returning a plain 401 without the Basic challenge. Browser navigations keep the normal Basic/form login flow. The shared fetch client (application-core api.js) now sends X-Requested-With so the fallback also matches, and its error catalog already maps 401 to "Your session has ended. Please sign in again." - which the shell now actually gets to display. Verified live: 401 without WWW-Authenticate for Sec-Fetch-Mode:cors and X-Requested-With requests; challenge kept for navigations and plain curl; authenticated calls unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
delchev
force-pushed
the
fix/no-basic-challenge-for-api-calls
branch
from
8112eb4 to
b8eb155
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
An expired session answers every request with
401 + WWW-Authenticate: Basic, so the browser pops its native login dialog before any script sees the response. The generated Harmonia apps poll/services/inbox/tasksevery 30 s, so an idle tab surfaces the dialog "out of nowhere" once the 8-hour session lapses (or the server restarts).Fix
BasicSecurityConfigregisters an additional authentication entry point for programmatic requests —Sec-Fetch-Modepresent and ≠navigate(every modern browser stamps fetch/XHR), withX-Requested-With: XMLHttpRequestas the legacy fallback — returning a plain 401 without the Basic challenge. Browser navigations keep the normal Basic/form login flow.The shared fetch client (
application-coreapi.js) now sendsX-Requested-With, and its error catalog already maps 401 to "Your session has ended. Please sign in again." — which the shell now actually gets to display instead of the dialog.Verified live
Sec-Fetch-Mode: cors, no sessionWWW-AuthenticateX-Requested-With: XMLHttpRequest, no sessionWWW-AuthenticateSec-Fetch-Mode: navigate, no session🤖 Generated with Claude Code