@askexenow/exe-os 0.9.371 → 0.9.373

package/deploy/compose/.env.customer.example

@@ -61,6 +61,23 @@ AUTH_DEFAULT_PRODUCT=AUTH
 # the sign-up UI/route instead of showing a form that always fails.
 AUTH_DISABLE_SIGNUP=true
 
+# --- Session cookie contract (exe-auth v0.6.0) — INFORMATIONAL, not settings ---
+# Recorded here because operators reason about XSS blast radius from this file,
+# and an earlier draft of these notes described the OPPOSITE of what ships.
+# exe-auth performs the GoTrue token exchange server-side in njs and sets:
+#   exe_sess          HttpOnly Secure SameSite=Lax  — the real access token
+#   exe_sess_refresh  HttpOnly Secure SameSite=Lax  — the real refresh token
+#   exe_access_token  JS-readable, value literally "1" — presence sentinel only
+# All three are scoped to the apex (AUTH_COOKIE_DOMAIN) so they are shared
+# across product subdomains.
+#
+# The credentials are HttpOnly ON PURPOSE (security bug 368bf916): page
+# JavaScript CANNOT read them, so an XSS on any subdomain cannot exfiltrate a
+# session token from document.cookie. The only JS-readable cookie is the
+# sentinel, whose value is the constant "1" and is not a credential.
+# Apps must NOT read a token from document.cookie — send credentialed
+# same-site requests and let the HttpOnly cookie ride along.
+
 # --- Centralized role administration (permissions) ---
 # The apps refuse to let an unmanaged first login mint its own admin
 # (exe-crm#102 / exe-wiki#45). Both flags below are therefore left at their

package/deploy/compose/.env.example

@@ -59,7 +59,7 @@ GOTRUE_EXTERNAL_URL=https://auth.CHANGEME_DOMAIN
 # Bug 51086951: JWT issuer pinned to the public auth URL so signer + consumers agree.
 GOTRUE_JWT_ISSUER=https://auth.CHANGEME_DOMAIN
 # SSO redirect allow-list (bug 66f8e10a) — app origins for unified SSO.
-GOTRUE_URI_ALLOW_LIST=https://crm.CHANGEME_DOMAIN,https://wiki.CHANGEME_DOMAIN,https://erp.CHANGEME_DOMAIN
+GOTRUE_URI_ALLOW_LIST=https://crm.CHANGEME_DOMAIN,https://wiki.CHANGEME_DOMAIN,https://erp.CHANGEME_DOMAIN,https://dashboard.CHANGEME_DOMAIN,https://gateway.CHANGEME_DOMAIN
 # Bug 0327b017: parent-domain cookie → session shared across all subdomains.
 GOTRUE_COOKIE_DOMAIN=.CHANGEME_DOMAIN
 GOTRUE_COOKIE_KEY=exe-auth
@@ -95,6 +95,23 @@ AUTH_DEFAULT_PRODUCT=AUTH
 # the sign-up UI/route instead of showing a form that always fails.
 AUTH_DISABLE_SIGNUP=true
 
+# --- Session cookie contract (exe-auth v0.6.0) — INFORMATIONAL, not settings ---
+# Recorded here because operators reason about XSS blast radius from this file,
+# and an earlier draft of these notes described the OPPOSITE of what ships.
+# exe-auth performs the GoTrue token exchange server-side in njs and sets:
+#   exe_sess          HttpOnly Secure SameSite=Lax  — the real access token
+#   exe_sess_refresh  HttpOnly Secure SameSite=Lax  — the real refresh token
+#   exe_access_token  JS-readable, value literally "1" — presence sentinel only
+# All three are scoped to the apex (AUTH_COOKIE_DOMAIN) so they are shared
+# across product subdomains.
+#
+# The credentials are HttpOnly ON PURPOSE (security bug 368bf916): page
+# JavaScript CANNOT read them, so an XSS on any subdomain cannot exfiltrate a
+# session token from document.cookie. The only JS-readable cookie is the
+# sentinel, whose value is the constant "1" and is not a credential.
+# Apps must NOT read a token from document.cookie — send credentialed
+# same-site requests and let the HttpOnly cookie ride along.
+
 # --- Centralized role administration (permissions) ---
 # The apps refuse to let an unmanaged first login mint its own admin
 # (exe-crm#102 / exe-wiki#45). Both flags below are therefore left at their

package/deploy/compose/docker-compose.yml

@@ -176,6 +176,17 @@ services:
       GOTRUE_API_PORT: ${GOTRUE_API_PORT:-9999}
       GOTRUE_DB_DRIVER: postgres
       GOTRUE_DB_DATABASE_URL: postgres://${POSTGRES_USER:-exe}:${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}@exe-db:5432/${POSTGRES_DB:-exedb}?sslmode=disable&search_path=auth
+      # Bug 5c3023a2: GoTrue's DB pool kept connections forever (Go database/sql
+      # ConnMaxLifetime defaults to 0). When exe-db (Postgres) restarts during a
+      # deploy, GoTrue reused a dead pooled socket for the next `error finding
+      # user` query → "write tcp ... broken pipe" → random 500 on /token
+      # (founder-visible sign-in failure). exe-db sets NO finite server-side idle
+      # timeout, so these bounds sit well below Postgres's ceiling and below any
+      # network idle reap: recycle every connection within 5m and drop an idle
+      # one after 60s, so a connection killed by a restart is retired, not reused.
+      GOTRUE_DB_MAX_POOL_SIZE: ${GOTRUE_DB_MAX_POOL_SIZE:-10}
+      GOTRUE_DB_CONN_MAX_LIFETIME: ${GOTRUE_DB_CONN_MAX_LIFETIME:-300s}
+      GOTRUE_DB_CONN_MAX_IDLE_TIME: ${GOTRUE_DB_CONN_MAX_IDLE_TIME:-60s}
       # Bug ae113b23: never fall back to a hardcoded domain here.
       # GOTRUE_SITE_URL must be set in .env by generate-env.ts. An empty/missing
       # value is intentionally rejected at runtime so misconfigured stacks fail
@@ -319,7 +330,11 @@ services:
       # the live exe-db-jkt container (image v0.9.4): /app/beszel exists,
       # /beszel does not → the old `/beszel` healthcheck failed on every probe
       # (permanent false-unhealthy). Match the image's own HEALTHCHECK path.
-      test: ["CMD", "/app/beszel", "health", "--url", "http://127.0.0.1:8090"]
+      # bug f9fc272b: the healthcheck binary is coupled to the image generation.
+      # stack-update writes MONITOR_HUB_HEALTH_BIN from the pinned manifest image
+      # so the probe follows the deployed generation; the default matches the
+      # v0.9.4 compose-default image.
+      test: ["CMD", "${MONITOR_HUB_HEALTH_BIN:-/app/beszel}", "health", "--url", "http://127.0.0.1:8090"]
       interval: 30s
       timeout: 5s
       start_period: 15s
@@ -879,6 +894,16 @@ services:
       # with (pinned on the gotrue service), NOT the internal GOTRUE_URL above, so
       # the gateway accepts real browser SSO tokens. Same public value, one default.
       GOTRUE_JWT_ISSUER: ${GOTRUE_JWT_ISSUER:-${GOTRUE_EXTERNAL_URL:?GOTRUE_EXTERNAL_URL is required — set to https://auth.<your-domain> in .env}}
+      # Bug 550d6ab7, third occurrence of the same defect (after exe-wiki
+      # 0c0d5187 and exe-crm). The gateway verifies GoTrue tokens IN-PROCESS:
+      # src/gotrue-auth.ts verifyGoTrueJWT reads the JWKS first and, because our
+      # GoTrue signs symmetrically and therefore publishes `{"keys":[]}` by
+      # design, falls back to getSymmetricKey() — which returns null unless
+      # GOTRUE_JWT_SECRET is in this container's environment. Without this line
+      # the fallback that makes gateway SSO possible at all is unsatisfiable in
+      # the stack customers actually run, and every token is rejected by a
+      # silent `return null`. Fail loud rather than boot with no key material.
+      GOTRUE_JWT_SECRET: ${GOTRUE_JWT_SECRET:?GOTRUE_JWT_SECRET is required}
       EXE_GATEWAY_WHATSAPP_VERIFY_TOKEN: ${EXE_GATEWAY_WHATSAPP_VERIFY_TOKEN:?EXE_GATEWAY_WHATSAPP_VERIFY_TOKEN is required}
       EXE_GATEWAY_WS_RELAY_ENABLED: "true"
       EXE_GATEWAY_WS_RELAY_HOST: "0.0.0.0"
@@ -1060,7 +1085,11 @@ services:
       # The binary-native `health` subcommand checks the freshness of the
       # agent's health file, which only stays fresh while it is actively
       # reporting to the hub.
-      test: ["CMD", "/app/beszel-agent", "health"]
+      # bug f9fc272b: the healthcheck binary is coupled to the image generation.
+      # stack-update writes MONITOR_AGENT_HEALTH_BIN from the pinned manifest image
+      # so the probe follows the deployed generation; the default matches the
+      # v0.9.4 compose-default image.
+      test: ["CMD", "${MONITOR_AGENT_HEALTH_BIN:-/app/beszel-agent}", "health"]
       interval: 30s
       timeout: 5s
       start_period: 30s
@@ -1296,7 +1325,7 @@ services:
   # 4 services: gunicorn API, websocket, RQ worker, scheduler.
 
   exe-erp:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
+    image: ${ERP_IMAGE_TAG:?ERP_IMAGE_TAG must be set by stack-update (the digest-pinned ERP image from the signed manifest) — refusing to fall back to an untested image}
     container_name: exe-erp
     restart: unless-stopped
     entrypoint: ["/usr/local/bin/entrypoint.sh"]
@@ -1437,7 +1466,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-erp-websocket:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
+    image: ${ERP_IMAGE_TAG:?ERP_IMAGE_TAG must be set by stack-update (the digest-pinned ERP image from the signed manifest) — refusing to fall back to an untested image}
     container_name: exe-erp-websocket
     restart: unless-stopped
     entrypoint: []
@@ -1499,7 +1528,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-erp-queue:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
+    image: ${ERP_IMAGE_TAG:?ERP_IMAGE_TAG must be set by stack-update (the digest-pinned ERP image from the signed manifest) — refusing to fall back to an untested image}
     container_name: exe-erp-queue
     restart: unless-stopped
     entrypoint: []
@@ -1531,15 +1560,41 @@ services:
       - backend
     healthcheck:
       # Liveness = the RQ worker process (PID 1) is still running.
-      # bug ed19883e: the slim Frappe base has NEITHER pgrep NOR ps/procps
-      # (exit 127 "not found") → the process-table probes were permanently
-      # false-unhealthy → 180s stack-update gate → rollback. Also `bench
-      # worker` runs the RQ worker in-process (frappe.utils.background_jobs
-      # .start_worker → Worker.work()); PID 1 argv stays "bench worker", so a
-      # `rq worker` grep would miss it even if ps existed. Use python (the
-      # image base is python:3.14-slim) to read PID 1's argv directly — this
-      # matches the exe-erp repo's own docker-compose.yml probe.
-      test: ["CMD-SHELL", "python -c \"import sys; cmd=open('/proc/1/cmdline','rb').read().replace(b'\\0', b' '); sys.exit(0 if b'bench worker' in cmd else 1)\""]
+      #
+      # TWO RULES, both learned the hard way. A probe must not (1) name a binary
+      # this image does not ship, nor (2) match a literal PID 1 never contains.
+      # Three generations shipped violating one or the other; each was aborted by
+      # the 180s stack-update health gate and auto-rolled-back, and none was ever
+      # diagnosed — together they account for >=8 dead erp deploys, Aug 7-10 2026:
+      #
+      #   gen 1  pgrep -f 'bench worker'
+      #          pgrep is absent from the slim base (exit 127) → false-unhealthy.
+      #   gen 2  ps -ef | grep -q '[r]q worker'            (bug c8fb434f)
+      #          Shipped as the FIX for gen 1, asserting "ps + grep are present".
+      #          ps is ALSO absent. This is what killed stack 0.9.33
+      #          (deploy-p1b.log:1592) and 0.9.34 (deploy-0.9.34.log:1698) on
+      #          exe-erp-queue. exe-erp itself came up healthy in both runs, so
+      #          the erp IMAGE was never at fault — only this probe was.
+      #   gen 3  python … b'bench worker' in /proc/1/cmdline  (bug ed19883e, #580)
+      #          Shipped as the FIX for gen 2 and verified only against a
+      #          SYNTHETIC PID1 argv. Its comment claimed 'PID 1 argv stays
+      #          "bench worker"'. THAT CLAIM IS FALSE, and is the whole bug:
+      #          `bench` execs away into the bench_helper module, so real PID 1 is
+      #            /home/frappe/frappe-bench/env/bin/python -m frappe.utils.bench_helper frappe worker --queue=…
+      #          The literal "bench worker" never appears. Measured exit 1 against
+      #          the live, genuinely-healthy production container on 2026-08-14.
+      #
+      # gen 4 (below) matches what PID 1 ACTUALLY is: "frappe worker". Measured
+      # exit 0 against that same live container, and proven end-to-end by
+      # recreating exe-erp-queue under Docker's own healthcheck runner: healthy in
+      # 10s, where gen 2 had burned the full 180s twice.
+      #
+      # The `tr` is LOAD-BEARING: /proc/1/cmdline is NUL-separated, so a bare
+      # `grep -q 'frappe worker' /proc/1/cmdline` returns 1 (also measured). Only
+      # sh, tr and grep are used — all three verified present in this image.
+      # Enforced by tests/deploy/compose/deploy-validation.test.ts, which checks
+      # every erp probe against a recorded inventory of the image's binaries.
+      test: ["CMD-SHELL", "tr '\\0' ' ' < /proc/1/cmdline | grep -q 'frappe worker'"]
       interval: 30s
       timeout: 5s
       start_period: 30s
@@ -1553,7 +1608,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-erp-scheduler:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
+    image: ${ERP_IMAGE_TAG:?ERP_IMAGE_TAG must be set by stack-update (the digest-pinned ERP image from the signed manifest) — refusing to fall back to an untested image}
     container_name: exe-erp-scheduler
     restart: unless-stopped
     entrypoint: []
@@ -1585,12 +1640,17 @@ services:
       - backend
     healthcheck:
       # Liveness = the scheduler process (PID 1) is still running.
-      # bug ed19883e: the slim Frappe base has NEITHER pgrep NOR ps/procps
-      # (exit 127 "not found") → the process-table probe was permanently
-      # false-unhealthy → 180s stack-update gate → rollback. Use python (the
-      # image base is python:3.14-slim) to read PID 1's argv directly — this
-      # matches the exe-erp repo's own docker-compose.yml probe.
-      test: ["CMD-SHELL", "python -c \"import sys; cmd=open('/proc/1/cmdline','rb').read().replace(b'\\0', b' '); sys.exit(0 if b'bench schedule' in cmd else 1)\""]
+      #
+      # Same three-generation history as exe-erp-queue above — read that comment
+      # for the full account (pgrep absent → ps absent → wrong literal). The
+      # short version: `bench schedule` execs away, so real PID 1 is
+      #   /home/frappe/frappe-bench/env/bin/python -m frappe.utils.bench_helper frappe schedule
+      # and the literal "bench schedule" never appears (measured exit 1 against
+      # the live container on 2026-08-14). Match "frappe schedule" instead —
+      # measured exit 0, and healthy in 10s on a real recreate.
+      # The `tr` is load-bearing: /proc/1/cmdline is NUL-separated.
+      # Enforced by tests/deploy/compose/deploy-validation.test.ts.
+      test: ["CMD-SHELL", "tr '\\0' ' ' < /proc/1/cmdline | grep -q 'frappe schedule'"]
       interval: 30s
       timeout: 5s
       start_period: 30s

package/deploy/compose/generate-env.ts

@@ -172,8 +172,8 @@ export function generateEnv(options: GenerateEnvOptions): string {
     "# http://gotrue:9999 and can reject browser tokens as iss-mismatch.",
     `GOTRUE_JWT_ISSUER=https://auth.${normalizedDomain}`,
     "# SSO redirect allow-list (bug 66f8e10a): app origins the gateway may bounce",
-    "# users back to via ?redirect=. Required for unified SSO across crm/wiki/erp.",
-    `GOTRUE_URI_ALLOW_LIST=https://crm.${normalizedDomain},https://wiki.${normalizedDomain},https://erp.${normalizedDomain}`,
+    "# users back to via ?redirect=. Required for unified SSO across crm/wiki/erp/dashboard/gateway (bug 2d2de534).",
+    `GOTRUE_URI_ALLOW_LIST=https://crm.${normalizedDomain},https://wiki.${normalizedDomain},https://erp.${normalizedDomain},https://dashboard.${normalizedDomain},https://gateway.${normalizedDomain}`,
     "# Bug 0327b017: scope the session cookie to the PARENT apex domain so it is",
     "# shared across crm/wiki/erp/auth subdomains → true SSO (no re-login).",
     `GOTRUE_COOKIE_DOMAIN=.${normalizedDomain}`,
@@ -466,7 +466,7 @@ export function generateExampleEnv(): string {
     "# Bug 51086951: JWT issuer pinned to the public auth URL so signer + consumers agree.",
     "GOTRUE_JWT_ISSUER=https://auth.CHANGEME_DOMAIN",
     "# SSO redirect allow-list (bug 66f8e10a) — app origins for unified SSO.",
-    "GOTRUE_URI_ALLOW_LIST=https://crm.CHANGEME_DOMAIN,https://wiki.CHANGEME_DOMAIN,https://erp.CHANGEME_DOMAIN",
+    "GOTRUE_URI_ALLOW_LIST=https://crm.CHANGEME_DOMAIN,https://wiki.CHANGEME_DOMAIN,https://erp.CHANGEME_DOMAIN,https://dashboard.CHANGEME_DOMAIN,https://gateway.CHANGEME_DOMAIN",
     "# Bug 0327b017: parent-domain cookie → session shared across all subdomains.",
     "GOTRUE_COOKIE_DOMAIN=.CHANGEME_DOMAIN",
     "GOTRUE_COOKIE_KEY=exe-auth",
@@ -502,6 +502,23 @@ export function generateExampleEnv(): string {
     "# the sign-up UI/route instead of showing a form that always fails.",
     "AUTH_DISABLE_SIGNUP=true",
     "",
+    "# --- Session cookie contract (exe-auth v0.6.0) \u2014 INFORMATIONAL, not settings ---",
+    "# Recorded here because operators reason about XSS blast radius from this file,",
+    "# and an earlier draft of these notes described the OPPOSITE of what ships.",
+    "# exe-auth performs the GoTrue token exchange server-side in njs and sets:",
+    "#   exe_sess          HttpOnly Secure SameSite=Lax  \u2014 the real access token",
+    "#   exe_sess_refresh  HttpOnly Secure SameSite=Lax  \u2014 the real refresh token",
+    "#   exe_access_token  JS-readable, value literally \"1\" \u2014 presence sentinel only",
+    "# All three are scoped to the apex (AUTH_COOKIE_DOMAIN) so they are shared",
+    "# across product subdomains.",
+    "#",
+    "# The credentials are HttpOnly ON PURPOSE (security bug 368bf916): page",
+    "# JavaScript CANNOT read them, so an XSS on any subdomain cannot exfiltrate a",
+    "# session token from document.cookie. The only JS-readable cookie is the",
+    "# sentinel, whose value is the constant \"1\" and is not a credential.",
+    "# Apps must NOT read a token from document.cookie \u2014 send credentialed",
+    "# same-site requests and let the HttpOnly cookie ride along.",
+    "",
     ...MANAGED_PERMS_ENV_BLOCK,
     "",
     "# --- CRM ---",

package/deploy/compose/sso-edge/default.conf.template

@@ -37,15 +37,47 @@ map $request_uri $sso_uri_access_token {
     "~[?&]access_token=(?<tok>[^&]+)" $tok;
 }
 
-# Extract the shared GoTrue session cookie (exe-auth, domain .${DOMAIN}) from
-# the Cookie header. Cross-app logout: GoTrue POST /logout clears this cookie
-# on the parent domain, so its absence signals a globally-revoked session.
-# The gate checks this alongside the app-native cookie — if the app cookie is
-# present but the GoTrue cookie is gone, the session was revoked on another app
-# and the edge forces re-auth (return 401 → login redirect).
+# Extract the shared apex SSO cookie from the Cookie header.
+#
+# THE COOKIE IS `exe_access_token` (bug 21ae2388). This map previously matched
+# `exe-auth` — a name NOTHING has ever set. That made the cross-app-logout arm
+# below fire on every single request, so any visitor holding a valid app-native
+# session was bounced back to auth forever. It is the FOURTH instance of one
+# recurring bug class: gating on a cookie name nothing mints. The first three
+# all gated on the retired `exe_sso_token` — exe-wiki f1bb40d8, exe-crm
+# 9f60e8e6, exe-erp 3938ac3d. See .github/workflows/sso-cookie-contract-monitor.yml.
+#
+# THE REAL CONTRACT (exe-auth v0.6.0, auth.njs.js setSessionCookies):
+#   exe_sess          HttpOnly Secure SameSite=Lax — the real access_token
+#   exe_sess_refresh  HttpOnly Secure SameSite=Lax — the real refresh_token
+#   exe_access_token  JS-readable, value literally "1" — presence sentinel
+# All three are scoped to the registrable apex (".${DOMAIN}") via
+# AUTH_COOKIE_DOMAIN, so they are presented across every product subdomain.
+# The two credentials are HttpOnly deliberately (security bug 368bf916) and are
+# therefore unusable as an edge signal; the sentinel is the one that is visible
+# here and is exactly what a presence gate needs.
+#
+# Cross-app logout: exe-auth's logout handler (clearSessionCookies) expires
+# exe_access_token on the apex, so its absence alongside a live app-native
+# cookie means the session was revoked on another app — the edge forces re-auth
+# (return 401 → login redirect).
+#
+# PRESENCE SIGNAL ONLY. The value is the literal "1", not a token. Never treat
+# it as a bearer credential and never forward it as one — the gate below tests
+# only whether it is empty. Token validation is step 3's GoTrue /user call.
 map $http_cookie $sso_gotrue_cookie {
     default "";
-    "~(?:^|;\s*)exe-auth=([^\s;]+)" $1;
+    "~(?:^|;\s*)exe_access_token=([^\s;]+)" $1;
+}
+
+# Static-asset exemption for the gate (see sso-redirect.conf step 0). Genuine
+# asset extensions only — every other path (HTML documents, all /api/* calls)
+# stays gated. Exempting assets is required for the SPA to boot at all: the
+# app sets its session cookie only after its JS runs, so gating app.js hands a
+# session-bearing document auth HTML in place of its script → blank page.
+map $uri $sso_is_static {
+    default "";
+    "~*\.(?:js|mjs|css|map|png|jpe?g|gif|svg|ico|webp|woff2?|ttf)$" "static";
 }
 
 map $http_upgrade $sso_conn_upgrade {

package/deploy/compose/sso-edge/sso-redirect.conf

@@ -7,13 +7,17 @@
 # advertised "single front door" does not exist.
 #
 # ── How it works ────────────────────────────────────────────────────────────
-#  1. Every request runs the edge auth gate (auth_request → /_sso_gate).
+#  0. Static assets (JS/CSS/images/fonts, via the $sso_is_static map) are
+#     exempted from the gate and answered 204 — see step 0 inside /_sso_gate
+#     for why gating them deadlocks first page load.
+#  1. Every other request runs the edge auth gate (auth_request → /_sso_gate).
 #  2. If the app session cookie is present the request passes (the app validates
 #     its own session server-side — the cookie name differs per app; set it via
 #     $sso_session_cookie below). Cross-app logout: the edge also checks for the
-#     shared GoTrue cookie (exe-auth on .${DOMAIN}); if the app cookie is present
-#     but the GoTrue cookie is gone, the session was revoked on another app and
-#     the edge forces re-auth.
+#     shared apex SSO cookie `exe_access_token` (set on .${DOMAIN} by exe-auth's
+#     njs handlers — a NON-CREDENTIAL presence sentinel whose value is literally
+#     "1"); if the app cookie is present but that sentinel is gone, the session
+#     was revoked on another app and the edge forces re-auth.
 #  3. If the request carries ?access_token= (the SSO callback), the edge
 #     VALIDATES the token against the shared GoTrue (`GET /user` with
 #     `Authorization: Bearer <token>`) before letting it through. P0 bug
@@ -22,6 +26,8 @@
 #     trusted — only a token GoTrue accepts passes.
 #  4. Anything else 401s inside the gate and is 302-redirected to:
 #       https://auth.<domain>/?product=<App>&redirect=https://<app>.<domain><uri>
+#     A 403 from the GoTrue /user validation subrequest is mapped to the same
+#     login redirect, so it is never leaked raw to the browser.
 #  5. The gateway authenticates against the shared GoTrue and bounces the user
 #     back to the app URL with ?access_token=<jwt>&refresh_token=<...>. The app
 #     consumes the token and sets its session cookie — subsequent requests carry
@@ -31,7 +37,7 @@
 # These are templated values — replace before installing, or render with envsubst
 # (DOMAIN, APP_NAME, APP_SUBDOMAIN, APP_SESSION_COOKIE):
 #
-#   # TWO http-context declarations MUST exist once per nginx config (the
+#   # FOUR http-context declarations MUST exist once per nginx config (the
 #   # compose edge ships them in sso-edge/default.conf.template; host-nginx
 #   # installs add them next to their `include`s — see sso-redirect.README.md):
 #   #
@@ -45,6 +51,19 @@
 #       default "";
 #       "~[?&]access_token=(?<tok>[^&]+)" $tok;
 #   }
+#   # 3. The shared apex SSO cookie — the cross-app-logout signal. The name is
+#   #    `exe_access_token` (bug 21ae2388: this used to read a nonexistent
+#   #    `exe-auth`, which 401'd every authenticated request). Presence only —
+#   #    the value is the literal "1", never a bearer token:
+#   map $http_cookie $sso_gotrue_cookie {
+#       default "";
+#       "~(?:^|;\s*)exe_access_token=([^\s;]+)" $1;
+#   }
+#   # 4. The static-asset exemption (see step 0 inside /_sso_gate):
+#   map $uri $sso_is_static {
+#       default "";
+#       "~*\.(?:js|mjs|css|map|png|jpe?g|gif|svg|ico|webp|woff2?|ttf)$" "static";
+#   }
 #
 #   server {
 #     server_name crm.${DOMAIN};
@@ -70,9 +89,30 @@
 # are app-native sessions the edge cannot verify against GoTrue); each app fully
 # validates its own session server-side. The edge gate's job is the login funnel
 # plus never letting an unvalidated bearer token skip it (bug 462d3273).
-# Cross-app logout adds a GoTrue-cookie check: if the app-native cookie is present
-# but the shared GoTrue cookie is absent, the edge 401s — the session was revoked
-# on another app and the app-native cookie is stale.
+# Cross-app logout adds a sentinel-cookie check: if the app-native cookie is
+# present but the shared apex `exe_access_token` sentinel is absent, the edge
+# 401s — the session was revoked on another app and the app-native cookie is
+# stale. This is ALWAYS ON; it is the mechanism that makes "log out once, out
+# everywhere" real across crm/wiki/erp/dashboard.
+#
+# ── SECURITY TRADEOFF: the static-asset exemption ────────────────────────────
+# Step 0 exempts requests from the gate by FILE EXTENSION, matching on $uri.
+# That is a URL-shape test, not a content test, so ANY application path whose
+# URI ends in .js/.mjs/.css/.map/.png/.jpe?g/.gif/.svg/.ico/.webp/.woff2?/.ttf
+# bypasses the edge gate — including user-uploaded content served under those
+# extensions, such as CRM attachments and wiki images.
+#
+# This is a deliberate, accepted tradeoff, on two grounds:
+#   1. Every app validates its own session server-side. The edge gate is the
+#      LOGIN FUNNEL, not the authorization boundary — an exempted request still
+#      reaches an app that will refuse to serve it to an unauthenticated user.
+#   2. Without the exemption the stack does not work at all: the SPA only sets
+#      its session cookie after its JS runs, so gating app.js returns auth HTML
+#      in place of the script and the app never boots (blank page).
+#
+# The limit of that reasoning: if you front something with this gate that does
+# NOT do its own authorization and serves secrets from an asset-extension URL,
+# the edge will not protect it. Do not rely on the edge gate in that case.
 # ─────────────────────────────────────────────────────────────────────────────
 
 # Run the gate for every request on this vhost. The gate is a zero-cost local
@@ -82,6 +122,11 @@
 # official nginx / nginx:alpine builds).
 auth_request /_sso_gate;
 error_page 401 = @sso_login;
+# A 403 from the gate's GoTrue /user validation must funnel to login too, not
+# leak raw to the browser. Safe: proxy_intercept_errors is not enabled on the
+# app proxy_pass blocks, so a genuine 403 from an upstream app is NOT converted
+# — only the auth_request subrequest's own status reaches this mapping.
+error_page 403 = @sso_login;
 
 location = /_sso_gate {
     internal;
@@ -93,12 +138,27 @@ location = /_sso_gate {
     # which auth_request rejects ("auth request unexpected status: 302").
     error_page 401 = @sso_gate_deny;
 
+    # 0. Static assets (JS/CSS/images/fonts via the $sso_is_static http-context
+    #    map) pass BEFORE any cookie check. Assets are non-sensitive — all SPA
+    #    data flows only via the authenticated APIs, which stay fully gated —
+    #    and gating them deadlocks first page load: the SPA sets its session
+    #    cookie only AFTER it boots, so answering app.js with the auth HTML
+    #    leaves a session-bearing document that can never boot (blank page).
+    #    See the SECURITY TRADEOFF note in the header for the limits of this.
+    if ($sso_is_static) {
+        return 204;
+    }
+
     # 1. App session cookie present → check for cross-app logout.
-    #    The GoTrue cookie (exe-auth, domain .${DOMAIN}) is shared across all
-    #    subdomains. GoTrue POST /logout clears it globally. If the app-native
-    #    cookie is present but the GoTrue cookie is gone, the session was
-    #    revoked on another app — force re-auth instead of trusting the stale
-    #    app cookie.
+    #    The shared apex cookie is `exe_access_token` (domain .${DOMAIN}), set
+    #    by exe-auth's njs login handler and expired by its logout handler. It
+    #    is a NON-CREDENTIAL presence sentinel — its value is literally "1", so
+    #    only its presence is meaningful and it is never used as a bearer token.
+    #    If the app-native cookie is present but the sentinel is gone, the
+    #    session was revoked on another app — force re-auth instead of trusting
+    #    the stale app cookie.
+    #    Bug 21ae2388: this arm matched a cookie named `exe-auth` that nothing
+    #    has ever minted, so it fired unconditionally and 401'd every request.
     set $sso_auth_check "";
     if ($sso_session_cookie) {
         set $sso_auth_check "app";

package/deploy/stack-manifests/v0.9.30-apps.json

@@ -52,7 +52,7 @@
           "env": "ERP_IMAGE_TAG",
           "composeService": "exe-erp",
           "healthUrl": "http://127.0.0.1:8069/api/method/ping",
-          "healthHost": "erp.askexe.com",
+          "healthHost": "${ERP_SITE_NAME:-erp.localhost}",
           "required": false,
           "category": "app",
           "description": "Enterprise Resource Planning"

package/deploy/stack-manifests/v0.9.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "latest": "0.9.35",
+  "latest": "0.9.36",
   "stacks": {
     "0.9.0": {
       "version": "0.9.0",
@@ -2689,11 +2689,126 @@
         }
       },
       "rolloutStage": "ga"
+    },
+    "0.9.36": {
+      "version": "0.9.36",
+      "releasedAt": "2026-08-14T06:50:39Z",
+      "notes": "SECURITY. exe-auth v0.6.0 — closes GoTrue's service_role admin API, which was publicly reachable on the customer auth host. Probed live against auth.askexe.com on v0.5.0: GET /api/admin/users returned 401 carrying x-sb-error-code: no_authorization — GoTrue ANSWERING, i.e. the request was proxied through to the admin API. nginx now returns a flat 404 for /api/admin/* and /api/invite/* (verified in the shipped image and at runtime); /api/settings and the user endpoints still proxy normally. Also: query strings are redacted from nginx access AND error logs (no token material in logs), the org-invite accept landing closes the dead link from exe-os #659, and the G2 build-provenance gate is armed fail-closed with its label reader fixed — v0.6.0 is the FIRST exe-auth image whose provenance was verified rather than assumed (all four checks green against this exact digest). v0.5.0 shipped 874941df and every fix landed the next day, so 0.9.35 has been serving the vulnerable build. Bumps the auth image digest ONLY; every other pin is identical to 0.9.35.",
+      "npmVersion": "0.9.324",
+      "services": {
+        "exe-db": {
+          "image": "update.askexe.com/askexe/pgvector:0.8.0-pg16@sha256:a132765ec351c65111b5b675928a3a0515a466a40f97277329db8b8209ad8bc9",
+          "env": "EXE_DB_IMAGE",
+          "composeService": "exe-db",
+          "required": true,
+          "category": "core",
+          "description": "Postgres (pgvector) — digest-pinned (bug 32d6e02f; was tag-only in 0.9.25, regressed from 0.9.24)"
+        },
+        "exe-os": {
+          "image": "update.askexe.com/askexe/exe-os:v0.9.324@sha256:3ce6406e0f7f279ff2568bbbb7d55de51a46fdf35c49691f24fd959d6fd2d3fa",
+          "env": "EXE_OS_IMAGE_TAG",
+          "composeService": "exe-os",
+          "healthUrl": "http://127.0.0.1:8765/health",
+          "required": true,
+          "category": "core",
+          "description": "exe-os daemon + MCP server"
+        },
+        "crm": {
+          "image": "update.askexe.com/askexe/exe-crm:v0.9.53@sha256:a586dcc8bbd992538e3caa18c44e772d30f31155dfef0a2b7466ca3fc7c553d8",
+          "env": "CRM_IMAGE_TAG",
+          "composeService": "exe-crm",
+          "healthUrl": "http://127.0.0.1:3000/healthz",
+          "category": "app"
+        },
+        "wiki": {
+          "image": "update.askexe.com/askexe/exe-wiki:v0.9.28@sha256:61856a4c6b97ce62c62ecdc3a377139287be5860eb807d9fbb737115758d7856",
+          "env": "WIKI_IMAGE_TAG",
+          "composeService": "exe-wiki",
+          "healthUrl": "http://127.0.0.1:3001/api/ping",
+          "category": "app"
+        },
+        "gateway": {
+          "image": "update.askexe.com/askexe/exe-gateway:v2026.08.07-c15f093-stamped@sha256:1bc11a2a0ad1f3929d59d2685696f22a72042b9fca9c75e15c02dc7d3c640105",
+          "env": "GATEWAY_IMAGE_TAG",
+          "composeService": "exe-gateway",
+          "healthUrl": "http://127.0.0.1:3100/health",
+          "category": "app",
+          "description": "WhatsApp/messaging gateway — provenance-stamped rebuild of main (outbound message persistence fix); pinned by digest, dated immutable tag.",
+          "gitSha": "c15f093a0f59730bd5c2c73791ff77059dfa7cc1"
+        },
+        "monitorAgent": {
+          "image": "update.askexe.com/askexe/exe-monitor-agent:v2026.08.09-10660eb4-stamped@sha256:29fbd445f79484df04f000603e4ff445e76f0380f86d687a0033e3a0ef7d1b7a",
+          "env": "MONITOR_AGENT_IMAGE_TAG",
+          "composeService": "exe-monitor-agent",
+          "category": "monitoring",
+          "gitSha": "10660eb4abdeffbcba2aad13549aa58e208ac7a3"
+        },
+        "monitorHub": {
+          "image": "update.askexe.com/askexe/exe-monitor-hub:v2026.08.09-10660eb4-stamped@sha256:c9a9218c2713b8dffea7e1cf8c0702a614657d311a7a4e821c6a543bab29bb97",
+          "env": "MONITOR_HUB_IMAGE_TAG",
+          "composeService": "exe-monitor-hub",
+          "healthUrl": "http://127.0.0.1:8090/api/health",
+          "category": "monitoring",
+          "gitSha": "10660eb4abdeffbcba2aad13549aa58e208ac7a3"
+        },
+        "auth": {
+          "image": "update.askexe.com/askexe/exe-auth:v0.6.1@sha256:89670a15bc59255299be695525863e66f949694eec1dd8886038dc3659a4a941",
+          "env": "AUTH_IMAGE_TAG",
+          "composeService": "exe-auth",
+          "healthUrl": "http://127.0.0.1:3300/api/health",
+          "category": "auth",
+          "description": "exe-auth v0.6.1 — the v0.6.0 hardening (GoTrue admin API no longer public; nginx 404s /api/admin|invite; query strings redacted from access + error logs) PLUS the four fixes that merged after v0.6.0 was tagged and had never been built into any image (bug 9e054a59): /api/recover CORS + method restriction (0f9fbebe); a recovery link can no longer mint a session and link hashes are sent as token_hash (056abf8d, c9b62c91); the Secure cookie flag fails closed and HSTS is set (bb99ceda); the session token is kept out of upstream request lines, shape-checked, and a service_role JWT is refused (bff591fe). Verified inside this exact digest, not from a green badge.",
+          "gitSha": "633e7a4d9930aad8b0ce6783a1b3bc2f96b454a8"
+        },
+        "erp": {
+          "image": "update.askexe.com/askexe/exe-erp:v2026.08.07-d185286-stamped@sha256:1c655f3f7819c797afd13c79561354f0276cf337403f32aee3e406a497e8827b",
+          "env": "ERP_IMAGE_TAG",
+          "composeService": "exe-erp",
+          "healthUrl": "http://127.0.0.1:8069/api/method/ping",
+          "healthHost": "localhost",
+          "required": false,
+          "category": "app",
+          "description": "Enterprise Resource Planning",
+          "gitSha": "d185286873dcfa11e4b3f9672c4e23efea240cc5"
+        },
+        "gotrue": {
+          "image": "update.askexe.com/askexe/gotrue:v2.172.1@sha256:b0dd7aa28dd1f9a8bd31f136c8b912661f701d9b863171e5843cb08f18f49de4",
+          "composeService": "gotrue",
+          "healthUrl": "http://127.0.0.1:9999/health",
+          "category": "infra"
+        },
+        "redis": {
+          "image": "update.askexe.com/askexe/redis:7.4-alpine@sha256:6ab0b6e7381779332f97b8ca76193e45b0756f38d4c0dcda72dbb3c32061ab99",
+          "composeService": "redis",
+          "category": "infra"
+        },
+        "clickhouse": {
+          "image": "update.askexe.com/askexe/clickhouse-server:24.8.4.13-alpine@sha256:88a45f9e328549b2579256c46ee38e5c0e25ae58303d9eb6d9c7ed8d6d2bbf3c",
+          "composeService": "clickhouse",
+          "category": "infra"
+        },
+        "cloudflared": {
+          "image": "update.askexe.com/askexe/cloudflared:2026-07@sha256:ba461b8aa9c042156dbd39c38657fe7431bafa063220eab8d5330a523863da9f",
+          "composeService": "cloudflared",
+          "category": "infra"
+        },
+        "exe-sso-edge": {
+          "image": "update.askexe.com/askexe/nginx:alpine@sha256:20316569d8f81a160065d7d2a5eeffc7ca97d79022462ee255fd23fa103a6b5c",
+          "composeService": "exe-sso-edge",
+          "category": "infra"
+        },
+        "exe-otel-collector": {
+          "image": "update.askexe.com/askexe/otel-collector-contrib:0.114.0@sha256:37fa87091cfaaec7234a27e4e395a40c31c2bfaea97a349a4afef6d9e9681197",
+          "composeService": "exe-otel-collector",
+          "category": "infra"
+        }
+      },
+      "rolloutStage": "ga"
     }
   },
   "signature": {
     "keyId": "exe-stack-1",
     "alg": "ed25519",
-    "signature": "pm9jH5HQp+Wo+eSqsFKBYekhFmSFUdJp1YYyBMqaufsnbOxj7JXakBGL4ssrzzi8s+xuNRY6SVXgXTT4biIpAg=="
+    "signature": "zJx3MxMUaco9bPRAPvmMs8qFXScuuAS9xWXSQBgtzKJB3ERe5aNvb+f6O39jWjxAvoPUQUObPjCuhwbu0aD8AQ=="
   }
 }

package/dist/.dist-verified.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "verified_at": "2026-08-14T03:02:39.069Z",
-  "manifest_sha256": "b29361778e3f781e393bbba4e4f24be7d1abff6d656d6d05b3740ac6e16d34c7",
-  "package_version": "0.9.371"
+  "verified_at": "2026-08-20T15:06:40.858Z",
+  "manifest_sha256": "b7074eb6ef6a4f0ce2cb5872b7c05033ee96e568c411773c0dfb9d7cc4a76f4b",
+  "package_version": "0.9.373"
 }