Skip to content

fix(ew): route block library through DA Preview Proxy - #1372

Open
dicagno wants to merge 6 commits into
mainfrom
libproxy
Open

fix(ew): route block library through DA Preview Proxy#1372
dicagno wants to merge 6 commits into
mainfrom
libproxy

Conversation

@dicagno

@dicagno dicagno commented Sep 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Description

Routes the canvas ("ew") block library through the DA Preview Proxy (preview.da.live) instead of loading content and previews directly from aem.page / aem.live.

Changes in blocks/canvas/ew-panel-extensions/helpers.js:

  • Library sources (calculateSources) are now built from getPreviewOrigin(org, site, ref) rather than …aem.live.
  • Variant HTML (getBlockVariants) rewrites AEM-hosted block URLs (ref--site--org.aem.page|live) to the proxy host before fetching (new toPreviewProxyUrl helper).
  • The preview iframe (getItemPreviewUrl) points at the proxy host.
  • Proxy fetches send credentials: 'include' so the session cookie is transmitted.
  • loadBlockLibrary defensively calls fetchWysiwygCookie to ensure the proxy's gimme_cookie session exists before fetching (the canvas editor already prefetches this on doc load; this covers the case where the library is the first thing to hit the proxy).

Reuses the canvas editor's existing getPreviewOrigin / fetchWysiwygCookie — no new eventing or auth mechanism introduced.

Related Issue

Fixes #1201

Motivation and Context

On protected (Helix-authenticated) sites, the block library fetched content straight from aem.page / aem.live, which returns a generic 401 when the user isn't authenticated via sidekick. Loading through the DA Preview Proxy lets the request authenticate with the user's existing DA session instead, so a signed-in DA user never sees the 401 — the token-exchange approach suggested in the issue. This mirrors the fix already applied to top-level apps in adobe/da-nx#618.

How Has This Been Tested?

  • Unit tests — added a DA Preview Proxy routing suite locking in that (1) the preview iframe URL, (2) AEM-hosted variant HTML fetches, and (3) configured library sources all route through the proxy host (never aem.page/aem.live) and send credentials. Full suite: npm test — the ew-panel-extensions suite passes 38/38; lint clean.
  • Manual — preview-iframe requests go to …stage-preview.da.live (not aem.page/aem.live), return 200, and send cookies, and gimme_cookie fires. Further tests might be performed against protected sites.

Test URL:

https://libproxy--da-live--adobe.aem.live/

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@dicagno @claude
fix(ew): route block library through DA Preview Proxy
5096d58 
The ew block library loaded content and previews directly from
aem.page/aem.live, which returns a 401 on protected sites when the
user isn't authenticated via sidekick (issue #1201).

Route library sources, variant HTML, and the preview iframe through the
DA Preview Proxy (preview.da.live) instead, using the canvas editor's
existing getPreviewOrigin. The proxy authenticates with the editor's DA
session cookie, so signed-in DA users no longer hit a 401. Proxy fetches
send credentials, and loadBlockLibrary defensively ensures the
gimme_cookie session before fetching.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@aem-code-sync

aem-code-sync Bot commented Sep 23, 2026 •
edited
Loading

Copy link
Copy Markdown

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch.
In case there are problems, just click the checkbox below to rerun the respective action.

  • Re-sync branch
Commits

@dicagno dicagno self-assigned this Sep 23, 2026
@dicagno
dicagno marked this pull request as ready for review September 23, 2026 14:17
@shsteimer shsteimer mentioned this pull request Sep 24, 2026
Open
6 of 10 tasks
dicagno and others added 2 commits September 29, 2026 16:26
@dicagno
Merge remote-tracking branch 'origin/main' into libproxy
fa6cb86
@dicagno
fix(ew): harden block library proxy routing for protected sites (#1201)
44e7cf3 
Follow-up review fixes for routing the library through the DA Preview Proxy:

- Send credentials only to the proxy. aem.page/aem.live answer with
  `Access-Control-Allow-Origin: *`, so credentialed requests to absolute
  library sources that aren't proxied failed CORS and the library came back
  empty. Absolute `branch--site--org.aem.*`/`hlx.*` sources are now rewritten
  through the proxy too (query and hash preserved; look-alike hosts untouched).
- Mint the proxy session cookie (memoized per org/site/branch) before every
  proxied request, not just in loadBlockLibrary: the side panel, option/editor
  sheets and template insertion now get it too, for the actual branch.
- Wait for that cookie before pointing the preview iframe at the proxy
  (new ensureItemPreviewAccess, used by the panel and the modal).
- Route insertTemplate through the proxy.
- Resolve inserted variant images against the public AEM origin again, so
  saved content never points at the auth-only proxy.
- When every library source answers 401/403, flag `authError` (not cached)
  and show an actionable "sign in with AEM Sidekick" message instead of
  "No blocks found".

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@hannessolo

hannessolo commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

The PR #1385 highlights that this will conflict with this PR.

I was initially suggesting to merge this 1372 (this PR) first, then have 1385 refactor the changes we merged here here. However, I noticed that 1385 covers one case this PR doesn't:

Cross-org access may regress. #1372 proxies absolute AEM URLs and cross-site block previews without checking whether the user has DA access to the target org. Someone who could view a protected site through AEM Sidekick but cannot obtain its DA proxy session may have had a working  aem.page  preview before and a 401 in the proxy iframe after. #1385 explicitly preserves cross-org plugin URLs for this reason; #1372 does not make that distinction.

@dicagno could you please port the shared preview-proxy module to this PR 1372, check that that fixes the case I found in this comment, and work with @shsteimer to check that it was implemented correctly here?

@shsteimer

shsteimer commented Sep 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

@dicagno if it's easier than porting that module here and you'd like to just apply your changes directly to the branch I have for #1385, plugprox that is fine with me. I can give it a once over and assuming I have no issue with it, then @hannessolo can do final review before we merge.

This branch was successfully deployed

1 active deployment
libproxy — 90afaa33 Deployed Sep 30, 2026 by aem-code-sync[bot]
View deployment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@dicagno dicagno

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[ew] Block library on protected Sites shows a generic 401 error when not authenticated via sidekick

3 participants

@dicagno @hannessolo @shsteimer