@valbuild/server 0.136.0 → 0.136.2

package/dist/valbuild-server.cjs.prod.js

@@ -4595,6 +4595,48 @@ class ValOps {
     return null;
   }
 
+  /**
+   * The branch the content service keeps this project's commits on, or `null`
+   * where there is no such service, or it has not said yet.
+   *
+   * For the Studio's in-tab build of a managed project, which has to name the
+   * branch its build was made at. Its other source is the `val.server.ts` the
+   * last build was wired with -- and a project cloned from a template seed has
+   * one wired at NO commit and no branch, so its first publish went out
+   * branchless and the loader refused it for a project whose pointer follows a
+   * branch. This is the project's own word for it.
+   */
+  projectBranch() {
+    return null;
+  }
+
+  /**
+   * Forward one call to the content service's publish API, as this project.
+   *
+   * The Studio builds a managed project in the tab and then has to publish what
+   * it built -- but a browser cannot talk to content directly. It holds a
+   * session cookie for THIS origin and no credential content would accept, so
+   * the conversation goes through here, exactly as patches already do.
+   *
+   * Refused by default, and that is the honest answer rather than a gap: `fs`
+   * and memory mode have no content service to forward to, and publishing there
+   * is writing to disk.
+   *
+   * The path is content's, minus the `/v1` prefix -- `/publish`,
+   * `/publish/{id}/artifacts`, `/build-target`. The ALLOW LIST lives in the
+   * implementation rather than here, because it is what keeps this from being
+   * a way to reach the rest of content with the project's credential.
+   */
+  async publishApi(_path, _init) {
+    return {
+      status: 501,
+      contentType: "application/json",
+      body: JSON.stringify({
+        message: "This Val server has no content service to publish through. " + "Publishing from the browser is for a project whose content is " + "served over HTTP."
+      })
+    };
+  }
+
   /**
    * Whether a commit here produces `.val.ts` TEXT as well as data.
    *
@@ -7492,6 +7534,42 @@ class FSOpsHost {
   }
 }
 
+/**
+ * The bytes of the local binary files a commit is about to write, base64.
+ *
+ * For the Studio's in-tab build of a managed project, which publishes the site:
+ * an image uploaded in this save is in no earlier build, so unless the build
+ * is given it the published page links a file that 404s. Remote files are left
+ * out -- they are served from their own URL and never were part of a build.
+ *
+ * A file that cannot be read is NAMED rather than dropped, and does not stop
+ * the save: the commit is what makes an edit durable, and the build is the
+ * step that can refuse.
+ *
+ * Read BEFORE the commit, because after it the files are no longer the
+ * patch's to read. Generic over the patch id so it asks for exactly the one
+ * method it uses, and a test can hand it a plain object.
+ */
+async function readCommittedBinaryFiles(ops, descriptors) {
+  const files = {};
+  const unread = [];
+  await Promise.all(Object.entries(descriptors).map(async ([filePath, {
+    patchId,
+    remote
+  }]) => {
+    if (remote) return;
+    const bytes = await ops.getBase64EncodedBinaryFileFromPatch(filePath, patchId, remote).catch(error => {
+      console.error("Could not read a committed file", filePath, error);
+      return null;
+    });
+    if (bytes === null) unread.push(filePath);else files[filePath] = bytes.toString("base64");
+  }));
+  return {
+    files,
+    unread: unread.sort()
+  };
+}
+
 /**
  * Which unpublished changes a failed save has to throw away to make progress.
  *
@@ -7973,6 +8051,189 @@ class ValOpsHttp extends ValOps {
     var _this$projectExpectat2;
     return ((_this$projectExpectat2 = this.projectExpectation) === null || _this$projectExpectat2 === void 0 ? void 0 : _this$projectExpectat2.sourceMode) ?? null;
   }
+
+  /** Remembered with {@link sourceMode}, from the same response. */
+  projectBranch() {
+    var _this$projectExpectat3;
+    return ((_this$projectExpectat3 = this.projectExpectation) === null || _this$projectExpectat3 === void 0 ? void 0 : _this$projectExpectat3.branch) ?? null;
+  }
+
+  /**
+   * The short-lived publish token, and when it stops being usable.
+   *
+   * `null` until something publishes, which for most deployments is never.
+   */
+  publishToken = null;
+
+  /**
+   * Trade this deployment's credential for one that can do one thing.
+   *
+   * Content's publish API takes a PROJECT TOKEN and nothing else --
+   * `authenticateProjectToken` refuses anything that is not one, deliberately,
+   * because a personal access token is a person's credential and does not name
+   * a project. What this deployment holds is the project's api key, which is
+   * neither.
+   *
+   * `POST /v1/{org}/{project}/publish-token` is the exchange, and it was built
+   * for exactly this: its own docblock names the case where "the caller was the
+   * project's api key ... a machine exchanging one machine credential for a
+   * narrower one". What comes back can publish one project for ten minutes.
+   *
+   * So the api key never leaves this process and the browser never sees any
+   * credential at all. That is the point of routing the publish through here
+   * rather than letting the tab talk to content.
+   */
+  async mintPublishToken() {
+    const res = await fetch(`${this.contentUrl}/v1/${this.project}/publish-token`, {
+      method: "POST",
+      headers: this.authHeaders
+    });
+    const text = await res.text();
+    if (!res.ok) {
+      return {
+        status: res.status,
+        error: `Could not get a publish token for '${this.project}': ` + `${res.status} ${text.slice(0, 300)}`
+      };
+    }
+    let parsed;
+    try {
+      parsed = JSON.parse(text);
+    } catch {
+      return {
+        status: 502,
+        error: "The publish token exchange did not answer with JSON."
+      };
+    }
+    const token = typeof parsed === "object" && parsed !== null && "token" in parsed && typeof parsed.token === "string" ? parsed.token : null;
+    if (token === null) {
+      return {
+        status: 502,
+        error: "The publish token exchange sent no token."
+      };
+    }
+    const expiresAtRaw = typeof parsed === "object" && parsed !== null && "expiresAt" in parsed ? parsed.expiresAt : null;
+    const expiresAt = typeof expiresAtRaw === "string" ? Date.parse(expiresAtRaw) : NaN;
+    return {
+      token,
+      /*
+       * A token with no expiry, or one we cannot read, is treated as expiring
+       * NOW -- so it is used for this call and minted again for the next.
+       * Caching one we cannot reason about is how a publish starts failing
+       * halfway through, days later, for no reason anyone can see.
+       */
+      expiresAt: Number.isFinite(expiresAt) ? expiresAt : 0
+    };
+  }
+
+  /**
+   * A usable publish token, minting one when what we have will not last.
+   *
+   * The margin is what stops a token that is valid when the publish starts from
+   * expiring in the middle of it: a publish is five calls and an upload of
+   * every artifact, and the upload is the slow one.
+   */
+  async currentPublishToken() {
+    const margin = 60_000;
+    if (this.publishToken !== null && this.publishToken.expiresAt - margin > Date.now()) {
+      return {
+        token: this.publishToken.token
+      };
+    }
+    const minted = await this.mintPublishToken();
+    if ("error" in minted) {
+      this.publishToken = null;
+      return minted;
+    }
+    this.publishToken = minted;
+    return {
+      token: minted.token
+    };
+  }
+
+  /**
+   * The content paths this may reach, and nothing else.
+   *
+   * An allow list rather than a prefix check, because this method holds a
+   * credential and the browser chooses the path. `/publish/{id}` and its three
+   * steps are the publish conversation; `/build-target` is what a build needs
+   * to know before it starts; `/project-source` is what it builds.
+   *
+   * `/project-source` is here rather than on a route of its own because it is
+   * one of the three things a publish asks for and none of them are useful
+   * apart -- and because the credential is the same one. The Studio cannot get
+   * the project's files any other way: it runs inside the deployment, which
+   * holds a session for its own origin and an api key for content, and content
+   * is the only thing it is allowed to talk to at all.
+   *
+   * A publish id is opaque and content-generated, so it is matched rather than
+   * parsed -- what matters is that nothing with a `..`, a query or another
+   * segment gets through.
+   */
+  static publishApiPathAllowed(path) {
+    if (path === "/build-target" || path === "/project-source" || path === "/publish") {
+      return true;
+    }
+    return /^\/publish\/[A-Za-z0-9_-]+(\/(artifacts|verify|promote))?$/.test(path);
+  }
+  async publishApi(path, init) {
+    const json = "application/json";
+    if (!ValOpsHttp.publishApiPathAllowed(path)) {
+      return {
+        status: 403,
+        contentType: json,
+        body: JSON.stringify({
+          message: `'${path}' is not part of the publish API.`
+        })
+      };
+    }
+    const send = async token => fetch(`${this.contentUrl}/v1${path}`, {
+      method: init.method,
+      headers: {
+        Authorization: `Bearer ${token}`,
+        ...(init.body === undefined ? {} : {
+          "Content-Type": json
+        })
+      },
+      ...(init.body === undefined ? {} : {
+        body: init.body
+      })
+    });
+    const credential = await this.currentPublishToken();
+    if ("error" in credential) {
+      return {
+        status: credential.status,
+        contentType: json,
+        body: JSON.stringify({
+          message: credential.error
+        })
+      };
+    }
+    let res = await send(credential.token);
+    if (res.status === 401) {
+      /*
+       * Revoked, or expired sooner than it said. One retry with a fresh token,
+       * because the alternative is a publish that fails for a reason the editor
+       * cannot act on and a retry that fails the same way.
+       */
+      this.publishToken = null;
+      const second = await this.currentPublishToken();
+      if ("error" in second) {
+        return {
+          status: second.status,
+          contentType: json,
+          body: JSON.stringify({
+            message: second.error
+          })
+        };
+      }
+      res = await send(second.token);
+    }
+    return {
+      status: res.status,
+      contentType: res.headers.get("content-type") ?? json,
+      body: await res.text()
+    };
+  }
   async onInit() {
     // TODO: unused for now. Implement or remove
   }
@@ -11531,6 +11792,38 @@ const ValServer = (valModules, options, callbacks) => {
       }
     };
   };
+
+  /**
+   * Hand one publish-API call to content and carry the answer back.
+   *
+   * `JSON.parse` and nothing more. That is not validation -- there is no schema
+   * here and no knowledge of content's shapes -- it is the round trip a JSON
+   * body has to make to travel as `json` rather than as a string. A body that
+   * does not parse is a gateway's error page rather than content answering, so
+   * it comes back as a message with the original status instead of throwing:
+   * a publish that failed is something the editor has to be told in words.
+   */
+  const proxyPublishApi = async (path, method, body) => {
+    const answer = await serverOps.publishApi(path ?? "", {
+      method,
+      ...(body === undefined ? {} : {
+        body
+      })
+    });
+    try {
+      return {
+        status: answer.status,
+        json: JSON.parse(answer.body)
+      };
+    } catch {
+      return {
+        status: answer.status,
+        json: {
+          message: answer.body.trim() === "" ? `The publish API answered ${answer.status} with no body.` : `The publish API answered ${answer.status}: ${answer.body.slice(0, 300)}`
+        }
+      };
+    }
+  };
   return {
     "/draft/enable": {
       GET: async req => {
@@ -11981,6 +12274,47 @@ const ValServer = (valModules, options, callbacks) => {
         };
       }
     },
+    /**
+     * The content service's publish API, reached through this deployment.
+     *
+     * The Studio builds a managed project in its own tab and then publishes
+     * what it built. It cannot talk to content directly -- it holds a session
+     * cookie for this origin and no credential content would accept -- so the
+     * whole conversation comes through here.
+     *
+     * Three things happen, and nothing else: the session is checked, the
+     * credential is swapped for a publish-scoped one (see
+     * `ValOpsHttp.publishApi`), and content's answer is carried back with its
+     * status intact. The Studio parses that answer with the same module
+     * `val publish` uses, so there is no copy of content's shapes here to
+     * fall out of step.
+     */
+    "/publish-api": {
+      GET: async req => {
+        const auth = getAuth(req.cookies);
+        if (auth.error) {
+          return {
+            status: 401,
+            json: {
+              message: auth.error
+            }
+          };
+        }
+        return proxyPublishApi(req.path, "GET");
+      },
+      POST: async req => {
+        const auth = getAuth(req.cookies);
+        if (auth.error) {
+          return {
+            status: 401,
+            json: {
+              message: auth.error
+            }
+          };
+        }
+        return proxyPublishApi(req.path, "POST", req.body === undefined ? undefined : JSON.stringify(req.body));
+      }
+    },
     "/upload/patches": {
       POST: async req => {
         if (serverOps instanceof ValOpsHttp) {
@@ -13480,6 +13814,12 @@ const ValServer = (valModules, options, callbacks) => {
               }
             }
             const message = body.message || "Val CMS update (" + Object.keys(analysis.patchesByModule).length + " files changed)";
+            /*
+             * Before the commit, because after it the files are no longer the
+             * patch's to read. See `binaryFiles` on the route.
+             */
+            const managedBranch = serverOps.sourceMode() === "managed" ? serverOps.projectBranch() : null;
+            const committedBinaries = serverOps.sourceMode() === "managed" ? await readCommittedBinaryFiles(serverOps, preparedCommit.patchedBinaryFilesDescriptors) : null;
             const commitToGit = () => {
               var _options$config$files;
               return serverOps.commit(preparedCommit, message, auth.id, ((_options$config$files = options.config.files) === null || _options$config$files === void 0 ? void 0 : _options$config$files.directory) || "/public/val", undefined,
@@ -13538,7 +13878,24 @@ const ValServer = (valModules, options, callbacks) => {
             return {
               status: 200,
               json: {
-                commitSha: commitRes.commit
+                commitSha: commitRes.commit,
+                /*
+                 * For the Studio to BUILD, when it is the deployer. See
+                 * `sourceFiles` on the route: the build must contain the text
+                 * this commit wrote, and only this handler has it.
+                 */
+                ...(serverOps.sourceMode() === "managed" ? {
+                  sourceFiles: preparedCommit.patchedSourceFiles
+                } : {}),
+                ...(managedBranch !== null ? {
+                  branch: managedBranch
+                } : {}),
+                ...(committedBinaries !== null ? {
+                  binaryFiles: committedBinaries.files,
+                  ...(committedBinaries.unread.length > 0 ? {
+                    binaryFilesUnread: committedBinaries.unread
+                  } : {})
+                } : {})
               }
             };
           }