hey! loving t3 code so far. running into one thing while self-hosting it and figured i'd write it up.
the setup
i run t3 code inside coder workspaces — one server per workspace, exposed through coder's reverse proxy. the proxy already does authn/authz (only the workspace owner can reach the port, over an authenticated tunnel), and the workspace is single-tenant. so from my side there's no threat model that the t3 auth layer is protecting against — it's a second lock on a door that's already locked, and it just adds a pairing prompt every time.
the problem
afaict there's no supported way to turn auth off for this case. serve always ends up on remote-reachable (or loopback-browser) and authenticateRequest hard-fails without a credential regardless of policy. the pieces are almost there though — ServerAuthPolicy already defines unsafe-no-auth in the schema, it's just never activated and no flag/env reaches it.
the workarounds don't really fit browser access behind a proxy:
auth pairing create tokens are one-time, so they can't be baked into a static proxy url and don't cover multiple devicesauth session issue bearer tokens are reusable but a browser navigation can't send an authorization header, so they don't help the web ui
so today the only thing that actually works is patching dist/bin.mjs at install time (force the policy to unsafe-no-auth and short-circuit authenticateRequest + authenticateWebSocketUpgrade to return an owner session). that's obviously brittle — e.g. authenticateWebSocketUpgrade went from (request) => Effect.gen(...) to Effect.fn(...) around 0.0.25 and quietly broke half the patch. really don't want to be maintaining string-replacements against a minified bundle.
the ask
a first-class opt-in for this — something like --unsafe-no-auth / T3CODE_UNSAFE_NO_AUTH=1 that actually activates the existing unsafe-no-auth policy and makes the request + ws-upgrade auth resolve to an owner session. loud naming is great, gate it behind the scary flag, print a warning on boot, whatever — just so people running behind a trusted proxy (coder, tailscale serve, a reverse proxy with sso in front, etc) have a supported path instead of patching internals.
thanks!
hey! loving t3 code so far. running into one thing while self-hosting it and figured i'd write it up.
the setup
i run t3 code inside coder workspaces — one server per workspace, exposed through coder's reverse proxy. the proxy already does authn/authz (only the workspace owner can reach the port, over an authenticated tunnel), and the workspace is single-tenant. so from my side there's no threat model that the t3 auth layer is protecting against — it's a second lock on a door that's already locked, and it just adds a pairing prompt every time.
the problem
afaict there's no supported way to turn auth off for this case.
servealways ends up onremote-reachable(orloopback-browser) andauthenticateRequesthard-fails without a credential regardless of policy. the pieces are almost there though —ServerAuthPolicyalready definesunsafe-no-authin the schema, it's just never activated and no flag/env reaches it.the workarounds don't really fit browser access behind a proxy:
auth pairing createtokens are one-time, so they can't be baked into a static proxy url and don't cover multiple devicesauth session issuebearer tokens are reusable but a browser navigation can't send anauthorizationheader, so they don't help the web uiso today the only thing that actually works is patching
dist/bin.mjsat install time (force the policy tounsafe-no-authand short-circuitauthenticateRequest+authenticateWebSocketUpgradeto return an owner session). that's obviously brittle — e.g.authenticateWebSocketUpgradewent from(request) => Effect.gen(...)toEffect.fn(...)around 0.0.25 and quietly broke half the patch. really don't want to be maintaining string-replacements against a minified bundle.the ask
a first-class opt-in for this — something like
--unsafe-no-auth/T3CODE_UNSAFE_NO_AUTH=1that actually activates the existingunsafe-no-authpolicy and makes the request + ws-upgrade auth resolve to an owner session. loud naming is great, gate it behind the scary flag, print a warning on boot, whatever — just so people running behind a trusted proxy (coder, tailscale serve, a reverse proxy with sso in front, etc) have a supported path instead of patching internals.thanks!