Structured-content preview/publish 401s on auth-enabled sites (window.open can't send Authorization header to da-sc)

[tyge68]

Summary

Preview/Publish for structured content in the /form editor 401s when the site has EDS authentication enabled (https://www.aem.live/docs/authentication-setup-site).

Reported in Slack: https://cq-dev.slack.com/archives/C08B6C02EPM/p1787596745867289
Repro: cisco-it-digital-workplace/ix-deploy, e.g.

• https://da-sc.adobeaem.workers.dev/preview/cisco-it-digital-workplace/ix-deploy/bridge/schemas/modals/lightbox-config
• https://da-sc.adobeaem.workers.dev/live/cisco-it-digital-workplace/ix-deploy/bridge/schemas/modals/lightbox-config

Root cause

nx2/blocks/ew-actions/ew-actions.js — the "Send" button (Preview/Publish) that wraps the /form structured-content editor:

• _runAemAction calls the AEM admin preview/publish API, then _resolveOpenUrl (lines ~217-229) resolves the URL to open: a preview-url/live-url <meta> template when the site defines one (BYO-origin override), else the AEM admin response URL.
• The resolved URL is opened with window.open(url, url) — a plain browser navigation to view the structured-content document as JSON via the da-sc delivery endpoint.
• Browser navigations cannot set custom request headers. da-sc (adobe-rnd/da-sc src/index.ts) only authenticates via Authorization: token <secret> forwarded from the incoming request — it has no cookie/session concept. Since that header can never be attached to a window.open navigation, any site whose preview-url/live-url meta points at da-sc.adobeaem.workers.dev 401s once site auth is enabled.
• This differs from normal aem.page/aem.live navigation, which authenticates via an interactive session cookie scoped to that origin — no equivalent flow exists for da-sc.

Impact

Any auth-enabled site relying on the preview/live URL override to view structured-content documents via da-sc cannot preview or verify a publish from the UI — it 401s every time.

Possible directions (not prescriptive)

• Support a cookie/session-based auth flow on da-sc mirroring aem.live's interactive login, so plain navigation works, or
• Route this preview through an authenticated fetch (rendering the JSON in-app) instead of a bare window.open to the delivery origin, or
• Document that preview-url/live-url overrides pointing at token-only origins are incompatible with EDS site auth today.

Out of scope

da-sc itself behaves correctly for callers that already carry an Authorization: token <secret> header (e.g. server-side/fetch-based consumers) — no change needed there.

[tyge68]

Considered and ruled out: reading the site secret client-side

One idea explored: since the UI already authenticates to admin.hlx.page to run preview/publish, could it also read the site's static auth secret from config/{org}/sites/{site}/secrets.json and use it as the Authorization: token <secret> header for the da-sc request?

Per https://www.aem.live/docs/authentication-setup-site:

• secrets.json is a POST-only creation endpoint — it mints a new secret and returns id/value once. There's no documented GET to read an existing secret's value back later (standard "shown once" secret pattern).

• More importantly, the docs draw a deliberate line between the two auth mechanisms:

  "The auth token for the admin API obtained during login... is highly sensitive and cannot be used for site authentication." vs. the site secret, which "can be shared with users and systems that need to access your site."

  The site secret is meant to be manually distributed by whoever administers the site (a config_admin-level operation), not minted or read on the fly by every visitor's browser session. Reading it live from the UI would likely:

  • Require a higher role than plain preview/publish (author/publish ≠ config_admin) — so it would 403 for most users who can currently click "Send".
  • Expose a long-lived shared secret to every client session that clicks Preview — exactly the anti-pattern the two-tier design (interactive IMS login vs. shared static secret) exists to avoid.

Better-aligned mechanism already in this repo

getAemSiteToken (nx2/utils/api.js, exchanges the signed-in user's IMS access token via POST ${HLX_ADMIN}/auth/adobe/exchange) derives a scoped token from the user's own session, server-side, rather than a shared static secret the client would have to fetch and hold. It's already used this way in nx/blocks/importer/index.js:

const result = await getAemSiteToken({ org, site: repo });
const siteToken = result?.siteToken || result?.token;
if (siteToken) {
  return { headers: { Authorization: `token ${siteToken}` } };
}

This is the pattern any fix here should build on — not reading secrets.json. It still doesn't solve the window.open header-attachment problem on its own (see issue body), but it answers "which token" cleanly and without the permission/security issues above.