Windows deep-link sign-in (cascade://) + web/server handoff#14
Merged
Conversation
Add a magic-link handoff so a Windows-initiated sign-in can complete in the desktop app instead of only the web app. Windows app: - Self-register the cascade:// URI scheme via WinAppSDK ActivationRegistrationManager (delivers a real Protocol activation; a hand-written HKCU command only yields a Launch activation). - Custom Program.Main: single-instance with activation redirection, so a cascade://auth?token=... handoff signs into the already-running app rather than spawning a second window. - Route the activating URI to the existing sign-in path (AppViewModel.SignInWithLinkAsync) and bring the window to front. Server: - /auth/request accepts an optional `platform`; "windows" appends &app=windows to the emailed link so the web /auth page can hand the single-use token to the desktop app instead of consuming it. Web: - When the link carries app=windows, hand the token to cascade:// (with a visible fallback link) instead of verifying it in the browser. Also fix a pre-existing bug where the signed-in/out view didn't update on runtime account changes: replace the x:Bind function-binding visibility (which didn't re-evaluate on Account changes) with notified Visibility properties, and marshal the 401 sign-out path onto the UI thread. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JacobStephens2
added a commit
that referenced
this pull request
Jun 7, 2026
PR #13's static /auth page shows the magic-link token with a Copy button and relies on Apple Universal Links to open the native app automatically. Windows has no Universal Link for an unpackaged app, so the link minted with &app=windows (server, #14) only ever showed the copy-the-code fallback. When app=windows is present, redirect to cascade://auth?token=... so the desktop app launches and signs in, with an "Open Cascade" button as the fallback if the browser blocks the programmatic protocol navigation. The copy-the-code path remains for when the app isn't installed. Co-authored-by: Jacob Stephens <jstephens@vagabondtours.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
2 participants
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.
What
Lets a Windows-initiated sign-in finish in the desktop app instead of only the web app, via a
cascade://magic-link handoff. Also fixes a pre-existing bug where the signed-in/out view didn't update on runtime account changes.Changes
Windows app
cascade://via WinAppSDKActivationRegistrationManager(real Protocol activation; a hand-written HKCU command only yields Launch).Program.Main: single-instance with activation redirection —cascade://auth?token=…signs into the already-running app, no second window.AppViewModel.SignInWithLinkAsyncand brings the window to front. Sendsplatform: "windows"on/auth/request.Server (
server/src/main.rs)/auth/requestaccepts optionalplatform;"windows"appends&app=windowsto the emailed link. Backward-compatible; no DB change.Web (
useSync.ts,AccountControls.tsx)app=windows, hand the single-use token tocascade://(with a visible fallback link) instead of verifying in the browser.Bug fix
x:Bindfunction bindings onAccountthat didn't re-evaluate at runtime, stranding the view after sign-out / a 401. Replaced with notifiedVisibilityproperties; marshal the 401 path onto the UI thread.Verified locally
cascade://auth?token=…→ routes to running app, no second window, writesaccount.json,GET /listening→ 200 for the new session.dotnet buildclean.Deploy note
"Click email link → opens Windows app" only takes effect once server + web are deployed. A
cascade://link only works when the email is opened on the same Windows machine.🤖 Generated with Claude Code