Repository navigation
fix(app): sign in from a link opened in the same tab, and say when the host refuses this browser - #614
Merged
Conversation
…e host refuses this browser
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.
Fixes #609 (map ^897). A tab already on the host's origin stayed on "Disconnected from your host. Reconnecting…" forever after its sign-in stopped working. Opening the sign-in link in that tab changed only the hash, so the app never read the new token. The socket's 401 showed only in the console.
host.tsreloads the page when the hash gains atoken, so the normal startup reads it, strips it from the URL, and connects with it./wsover HTTP every 5 s, sending the same token or cookie the socket would. A browser hides a WebSocket's 401, and this request doesn't. On a 401 the banner says: "This browser isn't signed in to your host. Runace openon that Mac, or open its sign-in link again." A host that's down still reads "Reconnecting…". The desktop app and the deployed web app keep their own messages.Smoke: isolated loopback host on port 4771 from this lane, rebuilt app, fresh headless Chromium:
http://localhost:4771/#channelswith no token showed the new sign-in banner instead of "Reconnecting…".http://localhost:4771/#token=<t>(a hash-only navigation) reloaded the page and connected. The token was stripped from the URL and the channel list loaded.I didn't test a real Ace Helper restart. That path is the same 401 on reload.
Built in Ace
No. Built by Claude Code as a fix worker after the two-Mac pair study because the worker runs outside an Ace channel. Dogfooding gap tracked in #5.