fix(vite): defer auth to the host when bridging a devframe#132
Merged
Conversation
A bridged devframe is a hosted deployment: the host app owns the origin and authentication. Stop the plugin's own OTP gate from firing in that context so a plugin mounted in a hub (or any host) never triggers its standalone auth, matching the documented hosted-adapter contract. viteDevBridge now runs its side-car RPC server with the plugin's auth gate off by default (ignoring cli.auth), overridable per-mount via a new `auth` option; createDevServer gains a matching `auth` override so hosted adapters can force the resolution while --no-auth still wins.
✅ Deploy Preview for devfra ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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
Bridging a devframe into a host (a Vite/Nuxt app, or a hub) is a hosted deployment: the host owns the origin and authentication. Yet
viteDevBridge's bridge mode delegated tocreateDevServer, which honorsdef.cli.auth(defaulttrue) — so a plugin mounted this way spun up its own interactive OTP gate and printed an auth banner, triggering standalone self-auth in a context where the host should manage it. This contradicted the contract documented on every built-in plugin: "Hosted adapters manage their own auth and ignore this." Onlyoghad noticed, working around it with an ad-hocauth: falseoption.Change
viteDevBridgenow runs its side-car RPC server with the bridged devframe's auth gate off by default (ignoringcli.auth), overridable per-mount via a newauth?: boolean | DevframeAuthHandleroption.createDevServergains a matchingauthoverride (highest precedence in the resolution) so hosted adapters can force the outcome; the--no-authflag still wins.og's now-obsolete auth workaround —OgVitePluginOptionsis justViteDevBridgeOptionsand forwards through.Because git, inspect, a11y, terminals, code-server, data-inspector, messages, og, and the Nuxt module all route through
viteDevBridge, every built-in plugin now uniformly defers auth to the host with no per-plugin code. Standalone behavior is unchanged — running a plugin via its CLI still gates by default.Verification
authoption forces the gate off over a gatedcli.auth; forces it on overcli.auth: false;--no-authstill wins overauth: true.pnpm build,pnpm typecheck,pnpm lint,pnpm testall green (855 tests).This PR was created with the help of an agent.