Forward the org selector header from the shared cloud session helpers

Rhys Sullivan committed 3 months ago

Commit 6fa5e8c1 parent 7f3cf091 file · +60 −30Browse files

Unified · Split

 //
 // Every one of these is a thin wrapper over a REAL product endpoint — there is
 // no back door here. They were copy-pasted verbatim into four cloud scenarios
-// before living here, and the copies drifted in the way that matters: only one
+// before living here, and the copies drifted in the two ways that matter, both
-// of them carried `forBrowser`, which is the fix for the fact that `joinOrg`
+// now folded in:
-// refreshes `headers.cookie` (the sealed session is re-issued on the new org)
+//
-// but leaves `cookies` on the PRE-join value — and the browser context is
+//   - only one carried `forBrowser`, the fix for the fact that `joinOrg`
-// seeded from `cookies`. A scenario using a stale copy browses as the person's
+//     refreshes `headers.cookie` (the sealed session is re-issued on the new
-// old org while its API calls use the new one.
+//     org) but leaves `cookies` on the PRE-join value — and the browser context
+//     is seeded from `cookies`. A scenario on a stale copy browses as the
+//     person's old org while its API calls use the new one.
+//   - only one forwarded the ORG SELECTOR header. Org-scoped endpoints fail
+//     closed without it (`AccountNoOrganization`), so a cookie-only copy cannot
+//     even build the fixture: `/api/account/members/invite` 403s.
 //
 // `cloud/*.test.ts` is a vitest `include` of `*.test.ts` only, so this module
 // is never collected as a suite.
 import type { Identity, Target as TargetShape } from "../../src/target";
+/**
+ * The per-request org selector. `/api/auth/switch-organization` was removed
+ * (#1000): the URL prefix or this header is the scope authority now, and the
+ * session's own org is only a default.
+ *
+ * This is the RIGHT way to read one account's data in a specific org: a session
+ * cookie captured before the account joined another org is stale the moment the
+ * later `accept-invitation` re-seals it, so holding onto the old cookie reads as
+ * an unauthenticated caller. Take the CURRENT identity and point it at the org
+ * you mean.
+ *
+ * Mirrors `ORG_SELECTOR_HEADER` in `apps/cloud/src/auth/organization.ts`
+ * (`EXECUTOR_ORG_SELECTOR_HEADER` in the SDK's shared exports); duplicated as a
+ * literal so the e2e suite stays a black-box client of the deployed product.
+ */
+const ORG_SELECTOR_HEADER = "x-executor-organization";
 /** The session cookie header this identity authenticates API calls with. */
 export const cookieOf = (identity: Identity): string => identity.headers?.["cookie"] ?? "";
 };
 /** POST as `identity`, failing loudly on a non-2xx (a silent skip here would
- *  leave the scenario asserting against a half-built fixture). */
+ *  leave the scenario asserting against a half-built fixture).
+ *
+ *  Sends the identity's OWN headers, not just its cookie: org-scoped endpoints
+ *  (`/api/account/members/invite` among them) fail closed with
+ *  `AccountNoOrganization` when the org selector header is absent, because the
+ *  session's own org is only a default and is never fallen back to. */
 export const postJson = (
   target: TargetShape,
   path: string,
     const response = await fetch(new URL(path, target.baseUrl), {
       method: "POST",
       headers: {
+        ...(identity.headers ?? {}),
         "content-type": "application/json",
         origin: new URL(target.baseUrl).origin,
-        cookie: cookieOf(identity),
       },
       body: JSON.stringify(body),
     });
     return response;
   });
-/** The identity re-bound to the refreshed session cookie a response set. */
+/** The identity re-bound to the refreshed session cookie a response set, and
-export const withRefreshedSession = (identity: Identity, response: Response): Identity => {
+ *  scoped to `orgSelector` — carrying the cookie alone would leave every
+ *  org-scoped read the identity goes on to make failing closed. */
+export const withRefreshedSession = (
+  identity: Identity,
+  response: Response,
+  orgSelector: string,
+): Identity => {
   const refreshed = (response.headers.getSetCookie?.() ?? [])
     .find((header) => header.startsWith("wos-session="))
     ?.split(";")[0];
   if (!refreshed) throw new Error("response did not refresh the session cookie");
-  return { ...identity, headers: { cookie: refreshed } };
+  return { ...identity, headers: { cookie: refreshed, [ORG_SELECTOR_HEADER]: orgSelector } };
+};
+/** The org selector this identity's requests carry — the same header the web
+ *  client derives from the console URL's slug. */
+export const orgSelectorOf = (identity: Identity): string => {
+  const selector = identity.headers?.[ORG_SELECTOR_HEADER];
+  if (!selector) throw new Error(`identity ${identity.label} carries no org selector header`);
+  return selector;
 };
 /**
  * invite carries no roleSlug, so the joiner lands as a plain MEMBER (the actor
  * an access-denial assertion needs); pass `roleSlug` for anything else.
  *
- * The returned identity is bound to the newly-joined org, because
+ * The returned identity is bound to the newly-joined org — the re-sealed
- * accept-invitation re-seals the session onto it. Calling this twice for one
+ * session from accept-invitation, scoped by the selector to the org they were
- * person is how a scenario builds a multi-org member: the WorkOS membership in
+ * invited INTO (`admin`'s). Calling this twice for one person is how a scenario
- * the earlier org persists, and the session simply points at the later one.
+ * builds a multi-org member: the WorkOS membership in the earlier org persists,
+ * and both the session and the selector point at the later one.
  */
 export const joinOrg = (
   target: TargetShape,
     const acceptResponse = yield* postJson(target, "/api/auth/accept-invitation", member, {
       invitationId: invitation.id,
     });
-    return withRefreshedSession(member, acceptResponse);
+    return withRefreshedSession(member, acceptResponse, orgSelectorOf(admin));
   });
 /** Create another org for this account; returns the identity bound to it. */
 ): Effect.Effect<Identity> =>
   Effect.gen(function* () {
     const response = yield* postJson(target, "/api/auth/create-organization", identity, { name });
-    return withRefreshedSession(identity, response);
+    const created = (yield* Effect.promise(() => response.clone().json())) as { id: string };
+    return withRefreshedSession(identity, response, created.id);
   });
-/**
- * The per-request org selector. `/api/auth/switch-organization` was removed
- * (#1000): the URL prefix or this header is the scope authority now, and the
- * session's own org is only a default.
- *
- * This is the RIGHT way to read one account's data in a specific org: a session
- * cookie captured before the account joined another org is stale the moment the
- * later `accept-invitation` re-seals it, so holding onto the old cookie reads as
- * an unauthenticated caller. Take the CURRENT identity and point it at the org
- * you mean.
- */
-const ORG_SELECTOR_HEADER = "x-executor-organization";
 /** This identity, scoped to `organizationId` for the requests it makes. */
 export const inOrg = (identity: Identity, organizationId: string): Identity => ({
   ...identity,

Forward the org selector header from the shared cloud session helpers

Keyboard shortcuts

General

Issues and pull requests

Issues, pull requests and Inbox

Repository code