feat(desktop,ui): sign the embedded artist UI in so a project switch doesn't ask for a password - #96
Merged
Merged
Conversation
…doesn't ask for a password
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
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
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.
Summary
Switching the project in use signed you out of the embedded artist UI, because sessions are stored per project — a token minted for A is invalid the moment B is active. That stays true for anything reaching the brain over the network; it is only wrong for the UI embedded in this desktop app, where the person at the keyboard already owns the store (they can read its secrets, add users, mint access keys), so re-typing a password into their own machine protects nothing.
The desktop now mints the session itself and hands it to the view it loads:
It is a real store session with a recognisable user agent, so it shows up in Access → Sessions and is revocable like any other login. The fragment (never a query) keeps the token out of the server's logs, and
takeTokenFromUrl()inuse-authconsumes it once and rewrites the address, preserving any other fragment the UI owns. No server change:/api/mevalidates this token exactly as it would one from the login form, so the handoff is transport, not privilege.One trap worth naming:
invalidateLaserView()used to callwebContents.reload(), which after the strip would reload a tokenless URL and land on the new project's login screen — the exact bug being fixed. It now re-loads throughembeddedUrl()with a fresh token.Also generalized
main-externals.test.tsto walksrc/main/*.tsinstead of a hand-maintained list, since a new main-process file importing a@wavegridpackage is precisely what it guards against (and this PR adds one).Verified against a running brain: a token minted this way returns
{"ok":true,"username":"dan","role":"admin"}from/api/me.pnpm test,pnpm build,pnpm lintpass.Link to Devin session: https://app.devin.ai/sessions/972698f89f494b86828010666a002b8f
Requested by: @pyramation