fix(hlx6): load hlx6 media images via authenticated source API

[kptdobe]

Summary

• Opening an image from the DA explorer on an hlx6 project (e.g. da-hlx6) loaded https://content.da.live/… which returns 404 for hlx6 content — images were broken
• For hlx6 repos, content lives behind api.aem.live and requires Bearer auth, not the cookie-based flow content.da.live uses
• Fix detects hlx6 via isHlx6(owner, repo), fetches the binary through source.get() (which handles Bearer auth), and replaces contentUrl with a blob: URL before passing it to <da-media>
• PDF files are unaffected (already load content separately via loadPdfMedia)
• Non-hlx6 repos: unchanged (contentLogin + content.da.live URL)

Test plan

Problem: https://da.live/media#/rofe/da-hlx6/firefly-gemini-flash-shy-pandamouse-drinkin-water-from-a-pond-922205.png

Fix: http://hlx6img--da-live--adobe.aem.live/media#/rofe/da-hlx6/firefly-gemini-flash-shy-pandamouse-drinkin-water-from-a-pond-922205.png

• Unit tests added: hlx6 image gets blob URL, non-hlx6 keeps content.da.live URL, pathDetails cache object not mutated
• Open an image from the explorer in an hlx6 project — verify it renders
• Open an image in a non-hlx6 project — verify no regression

🤖 Generated with Claude Code

[aem-code-sync]

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

• db12dd6 ✅ (latest)

[bosschaert]

I guess the Fix URL is wrong. Should it be https://hlx6img--da-live--adobe.aem.live/media#/rofe/da-hlx6/firefly-gemini-flash-shy-pandamouse-drinkin-water-from-a-pond-922205.png ?

[andreituicu]

Just a thought, instead of using blob urls, you could add the Helix 6 source API to the preview proxy as a place to retrieve images from
https://github.com/adobe/da-universal/blob/main/src/handlers/get.js#L33-L36

and then rewrite the media block source to use the preview proxy, just like it is going to work in the editor via #930 .

That way, you have unified the access to images inside DA.live through the cookie based approach of the Preview Proxy.

It is not super clear to me if images uploaded in Helix 6 media bus are immediately available of .aem.page.

[kptdobe]

Just a thought, instead of using blob urls, you could add the Helix 6 source API to the preview proxy as a place to retrieve images from https://github.com/adobe/da-universal/blob/main/src/handlers/get.js#L33-L36

and then rewrite the media block source to use the preview proxy, just like it is going to work in the editor via #930 .

That way, you have unified the access to images inside DA.live through the cookie based approach of the Preview Proxy.

It is not super clear to me if images uploaded in Helix 6 media bus are immediately available of .aem.page.

Stupid question: why we don't do it the other way around and do not use a proxy in the editor... ?

[andreituicu]

Stupid question: why we don't do it the other way around and do not use a proxy in the editor... ?

Blob URLs cannot be sent over to iframes.
They only work within the frame they were created.
In order to recreate the blob URL inside the preview iframes, the user's IMS token would have to be sent over too, inside the frame where all the rendering scripts and full martech stack execute.

That is why we came up with the preview proxy solition, where the IMS token is set as a HTTPOnly cookie and can only be read by the server. Scripts inside the frame cannot physically access it.

[kptdobe]

ok, changed the implementation to go to the preview proxy. Next issue: I assume the preview proxy is not hlx6 ready... I get a 404 for the image.

[tripodsan]

ok, changed the implementation to go to the preview proxy. Next issue: I assume the preview proxy is not hlx6 ready... I get a 404 for the image.

that's because the image lives in the source bus until it's previewed (like a plain image in sharepoint lives in sharepoint).

https://api.aem.live/rofe/sites/da-hlx6/source/firefly-gemini-flash-shy-pandamouse-drinkin-water-from-a-pond-922205.png

i.e. for now, the previous solution with the content url was better.

[andreituicu]

https://api.aem.live/rofe/sites/da-hlx6/source/firefly-gemini-flash-shy-pandamouse-drinkin-water-from-a-pond-922205.png

@tripodsan: The preview proxy can fetch it from there https://api.aem.live/rofe/sites/da-hlx6/source/firefly-gemini-flash-shy-pandamouse-drinkin-water-from-a-pond-922205.png and return it, just like it returned it before from admin.da.live. It will need to be made to work with Helix 6 images anyway, because otherwise live preview, quick edit, etc. would not work.

So it is a matter of starting to add support for Helix 6 inside of the preview proxy, if you'd like individually for images with a helix6SourceGet in: https://github.com/adobe/da-universal/blob/main/src/handlers/get.js#L33-L36 or directly inside daSourceGet, because I imagine that slowly documents would need to be retrieved from there too.

[tripodsan]

So it is a matter of starting to add support for Helix 6 inside of the preview proxy,

...
but why? I always thought, that eventually, admin.da.live is no longer needed and the editor operates directly on the api.aem.live.

[andreituicu]

but why? I always thought, that eventually, admin.da.live is no longer needed and the editor operates directly on the api.aem.live.

The document editor is just 1 of the ways to visualise or edit the content and the only one that works directly on the native document view that is stored in source bus, without the need to do a full page rendering.

There are at least 3 views: (Live Preview, Quick Edit, Universal Editor) which either help visualise or actually edit on top of the un-previewed rendered page, the WYSIWG functionality. The preview proxy is the one providing the underlining "show me the rendered page, while still keeping my content un-previewed". So it needs to understand where to get the unpreviewed content even for Helix 6 scenarios.

Having the cookie being set on api.aem.live for a similar purpose would not be great, because it doesn't provide origin separation to the sites, if we were to use it for full page rendering, including scripts. the main--${site}--${org}.preview.da.live helps preserve this origin separation.

And these are just the built-in DA functionality. External systems (like for example our Governance Agent) also want to see the rendered page for auditing purposes (e.g. create a screenshot).

[kptdobe]

starting to add support for Helix 6 inside of the preview proxy

The proxy would need to make the ping request to determine if this is an hlx6 project. Or we need to set it in the client side code "somewhere" (cookie ?)

[andreituicu]

starting to add support for Helix 6 inside of the preview proxy

The proxy would need to make the ping request to determine if this is an hlx6 project. Or we need to set it in the code "somewhere".

The ping would be 1 option. The other would be skipping the ping and just try to load from hlx6, if it isn't there, fallback to admin.da.live. Either way, there will be 2 requests.

Could even be started in parallel and then just do the fallback mechanism on the responses. (this would be a little bit wasteful for the case of hlx6 which for the moment will be less dominant, but faster for the fallback case)

[kptdobe]

I created adobe/da-universal#242.
Can be tested on stage, works as expected: https://hlx6img--da-live--adobe.aem.live/media?da-live-preview=stage#/rofe/da-hlx6/firefly-gemini-flash-shy-pandamouse-drinkin-water-from-a-pond-922205.png