@valbuild/server 0.121.0 → 0.122.0

package/dist/declarations/src/tools/types.d.ts

@@ -75,51 +75,42 @@ export type ValToolDefinitionJson = Omit<ValToolDefinition, "inputSchema"> & {
     inputSchema: ReturnType<typeof z.toJSONSchema<z.ZodType>>;
 };
 /**
- * How the caller was established, and it is a union because there are two
- * genuinely different answers — with different consequences downstream.
+ * How the caller was established, and there is one acceptable answer: the host
+ * **checked a signature**.
  *
- * The distinction that matters is **who checked**. A PAT is forwarded to the
- * backend unchecked, because the app cannot resolve one; an access token is
- * verified by the app itself, against a public key it does not hold and
- * therefore cannot forge. The first is a credential being relayed. The second
- * is a signature that has already been checked.
+ * A union of one, deliberately. It carried a second variant — a personal access
+ * token relayed to the backend unchecked, on the reasoning that the app cannot
+ * resolve one and the backend can. The reasoning held; the shape did not. A
+ * credential the host cannot check is one it also cannot refuse, so accepting
+ * one made "a deployed endpoint that authenticates nobody" a supported
+ * configuration, and it let a host serve these tools without ever being told
+ * where callers should authorize. The discriminant stays so that adding a
+ * second *verified* kind stays a one-line change at every call site.
  */
 export type ValToolAuth = {
-    type: "pat";
-    /**
-     * The caller's PAT. Never log this, never put it in a URL, and never let
-     * it reach a tool result.
-     *
-     * Relayed to the backend as-is: this app is not the authority on what the
-     * token may do, and the backend that is decides. Nothing is derived from
-     * it here — see `docs/plans/mcp.md` D.2.
-     */
-    pat: string;
-} | {
     type: "verified-profile";
     /**
      * The profile the host **verified** — the `sub` of an access token whose
      * signature, issuer, audience and expiry were all checked against the
      * authorization server's published key.
      *
-     * This field is the reason this type became a union, and an earlier
-     * version of this file argued no identity field should exist at all. That
-     * argument was about a specific case and stated too broadly: an id the
-     * host *asserts* on the strength of a credential it cannot check is an
-     * unverified claim dressed as a checked one, and that is still refused —
-     * it is why the `pat` variant carries no profile. An id the host
-     * *verified* cryptographically is a different thing, and it is the same
-     * standing the Studio has when it re-signs a session it established
-     * itself.
+     * This field is why an identity field exists at all, and an earlier version
+     * of this file argued none should. That argument was about a specific case
+     * and stated too broadly: an id the host *asserts* on the strength of a
+     * credential it cannot check is an unverified claim dressed as a checked one,
+     * and that is still refused — it is why a relayed token never carried a
+     * profile, and now cannot reach here at all. An id the host *verified*
+     * cryptographically is a different thing, and it is the same standing the
+     * Studio has when it re-signs a session it established itself.
      */
     profileId: AuthorId;
     /**
      * The token's granted scopes, as the authorization server issued them.
      *
-     * Enforced here as well as by the backend, deliberately. Two checks on
-     * one grant is not redundancy for its own sake: this one can refuse a
-     * write before it is attempted, so a token that may only read never
-     * reaches the code that builds a patch.
+     * Enforced here as well as by the backend, deliberately. Two checks on one
+     * grant is not redundancy for its own sake: this one can refuse a write
+     * before it is attempted, so a token that may only read never reaches the
+     * code that builds a patch.
      */
     scopes: string[];
 };

package/dist/declarations/src/valServerConfig.d.ts

@@ -36,22 +36,25 @@ export declare function initHandlerOptions(route: string, opts: ValApiOptions, c
 /**
  * Build the data layer a {@link ValServerConfig} calls for.
  *
- * `auth` decides *whose* credential the http backend sees. Left out, it is the
- * app's own API key — which is what the Studio wants, because there the app has
- * already verified a session cookie and is acting on the user's behalf under its
- * own authority.
+ * The http backend always sees the app's own API key. That is what the Studio
+ * wants — there the app has already verified a session cookie and is acting on
+ * the user's behalf under its own authority — and it is now the only shape:
+ * every caller that reaches here has been authenticated by the app itself, so
+ * there is no request left on which the app is a pipe rather than an authority.
  *
- * A caller acting for a user it has *not* authenticated itself must pass that
- * user's personal access token instead, so the backend is the one that decides
- * what the caller may do. That is the whole of `docs/plans/mcp.md` D.2: the app
- * stops being an authority and goes back to being a pipe. Passing the app's API
- * key on such a request is the D.6 confused deputy, and it is worth being blunt
- * about why it is tempting — it works, and it works for every project the key
- * can reach, including the ones the caller cannot.
+ * This took a parameter for the other case: a caller acting for a user it had
+ * *not* authenticated passed that user's personal access token, and the backend
+ * decided what the caller could do. `ValOpsHttp` still accepts such a token —
+ * the CLI's `debug` command uses the developer's own from `val login` — but no
+ * server request builds one any more, because a request the app cannot
+ * authenticate is now refused instead of relayed.
+ *
+ * What has not changed is why the API key must never stand in for a credential
+ * that was merely *absent*: it works, and it works for every project the key
+ * can reach, including the ones the caller cannot. Callers are refused for a
+ * missing credential well before this point.
  */
-export declare function createValOps(valModules: ValModules, options: ValServerConfig, auth?: {
-    pat: string;
-}): ValOpsFS | ValOpsHttp;
+export declare function createValOps(valModules: ValModules, options: ValServerConfig): ValOpsFS | ValOpsHttp;
 /**
  * Hosts we send credentials to, and what each one puts at risk. They differ:
  * only `valBuildUrl` hands back the app token that becomes the session cookie,