Media lib Quality Improvements by kmurugulla · Pull Request #581 · adobe/da-nx

kmurugulla · 2026-07-07T16:07:30Z

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):

Fix #

Test URLs:

Notes

Replace hardcoded HTTP status codes (401, 403, 500) with HttpStatus constants across 12 files
Centralize CSS background colors into custom properties (--ml-bg, --ml-surface, --ml-topbar-bg) for consistent theming
Fix error propagation in worker to preserve status codes without fragile string parsing
Add error hints to permission-denied errors for better user guidance
Centralize hardcoded user messages into core/messages.js for maintainability
Add user-friendly validation error messages with actionable suggestions
Fix dark mode backgrounds to use consistent color system
Clarify medialog access requirements in error messages (author role or higher needed)
Fix plugin mode preview authentication using daFetch.initIms

aem-code-sync · 2026-07-07T16:07:34Z

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

a361f06 ✅ (latest)
9a1b48c ✅
5c247e6 ✅
3c3f042 ✅
5bbc395 ✅
eb78245 ✅
c41165d ✅
51870cb ✅
e1abe64 ✅
5537a7d ✅
b0f5c10 ✅

mhaack · 2026-07-08T07:17:18Z

      }

-      if (resp.status === 401 || resp.status === 403) {
+      if (resp.status === HttpStatus.UNAUTHORIZED || resp.status === HttpStatus.FORBIDDEN) {


Not sure if this is really needed? The status numbers are pretty common, don't know if we should have a constant for this.

✅ Resolved - Reverted to using magic numbers for consistency with the rest of the codebase. Other blocks (outside media-library) also use magic numbers for HTTP status checks.

Commit: bcdd9b0 - refactor: use HTTP status code numbers for consistency with codebase

mhaack · 2026-07-08T07:19:01Z

+  --ml-bg: light-dark(rgb(249 249 249), rgb(28 28 28));
+  --ml-surface: light-dark(rgb(255 255 255), rgb(26 26 26));
+  --ml-topbar-bg: light-dark(rgb(248 248 248), rgb(27 27 27));


IHMO we should stick with the spectrum styles. With NX2 you will also get light/dark mode

✅ Resolved - Switched to nx2 Spectrum styles with inline light-dark() pattern for consistent dark mode support across all components.

Changed from custom CSS variables (--ml-bg, --ml-surface, etc.) to inline light-dark(rgb(...), rgb(...)) values, matching the pattern used by sidebar and ensuring proper dark mode in shadow DOM components.

Commits:

830c804 - refactor: replace custom CSS variables with inline light-dark() for consistent dark mode

5bc18fa - refactor: remove misleading CSS comment about variable inheritance

mhaack · 2026-07-08T07:20:04Z

t is pretty short. I think is this on other places as well.

✅ Resolved - Renamed t() to getMessage() across all 13 files for better clarity since this is not i18n.

Commit: d128547 - refactor: rename t() to getMessage() for clarity

mhaack · 2026-07-08T07:24:01Z

  try {
-    const { loadIms } = await import('../../../../nx2/utils/ims.js');
-    const { accessToken } = await loadIms() || {};
+    const { initIms } = await import('../../../utils/daFetch.js');


While this might work we should use NX2, so we can remove NX.

Also there is const { loadIms } = await import('../../utils/ims.js');util which is maybe used better here https://github.com/adobe/da-nx/blob/main/nx/utils/ims.js

We're using nx here instead of nx2 because nx provides the setImsDetails(token) function in daFetch.js which enables token injection in plugin mode. This capability is critical for the SDK integration where tokens need to be injected externally.

Currently, nx2 doesn't have this token injection capability. Should we enhance nx2 to support this use case so we can eventually migrate away from nx?

Not sure I fully understand the flow and usage of setImsDetails(...) are you doing a different IMS login?

Also would like to get a thought from @andreituicu on this from security pov.

Good question! Here's the flow:

Current Implementation (using nx)

The media library supports plugin mode where it runs embedded in another application (like Adobe Express or other Adobe tools). In this mode:

Host app handles authentication: The parent application already has an authenticated IMS session

Token is passed via MessagePort: The parent sends the IMS token through postMessage when initializing the SDK (see nx/utils/sdk.js:70-71)

Token is injected: setImsDetails(token) stores this externally-provided token

No duplicate auth: The media library reuses the host's token instead of triggering its own IMS login

Code flow:

// In host app mediaLibraryIframe.contentWindow.postMessage({ ready: true, token }, '*', [messagePort]) // In media library (nx/utils/sdk.js:70-71) if (e.data.token) { setImsDetails(e.data.token); // Inject external token } // Later in daFetch (nx/utils/daFetch.js:22-24) if (imsDetails) { // Use injected token const { accessToken } = await initIms(); opts.headers.Authorization = `Bearer ${accessToken.token}`; }

nx2 Limitation

nx2/utils/ims.js always calls loadIms() which:

Loads the Adobe IMS library directly

Performs its own authentication flow

Has no mechanism to accept externally-provided tokens

Security Note

This is not a "different IMS login" - it's reusing an already-authenticated token from a trusted parent application. The host app has already completed Adobe IMS authentication; we're just accepting that token rather than forcing a second auth.

@andreituicu - Would appreciate your security review on this approach. The alternative would be to add setImsDetails() capability to nx2.

🤔 For the use case of the embedding in non-DA properties I think this should either live somewhere else or in some Media Library only code, not in a shared one.

if we need special handling for IMS here for this use case this not be part of NX or DA core.

in this specific use case , the media library code from da-nx is being loaded via da.live in the plugin mode. Plugin being used in layout / da editor mode. Even though plugin code is part of non-da.live related repo, as the plugin is loaded on da.live , i thought i would reuse as much as possible from da-nx.

I am open to move the specific IMS functionalities that will enable me to reuse code between app and plugin into media library , however it will sort of creates duplication of code. And i don't know whether there are any other apps that needed this model of reuse app and plugin from same code base.

Plugin reference - https://github.com/adobe-rnd/aem-apps/blob/main/tools/plugins/media-library/media-library.html

@mhaack Since I have couple of other changes added into this PR , if it is agreeable , i can take up the IMS related functionality ( moving into media library) in another PR

- Replace hardcoded HTTP status codes (401, 403, 500) with HttpStatus constants across 12 files - Centralize CSS background colors into custom properties (--ml-bg, --ml-surface, --ml-topbar-bg) - Fix error propagation in worker to preserve status codes without string parsing - Add error hints to DA_READ_DENIED for consistent user guidance - Fix import path for HttpStatus in worker/fetch.js 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>

…onsistent dark mode

…remove redundant auditlog fetch

kmurugulla requested a review from mhaack July 7, 2026 16:07

kmurugulla force-pushed the medialib-quality branch from 607e2b6 to 8b069dd Compare July 7, 2026 16:09

aem-code-sync Bot temporarily deployed to medialib-quality July 7, 2026 16:09 Inactive

mhaack reviewed Jul 8, 2026

View reviewed changes

aem-code-sync Bot temporarily deployed to medialib-quality July 8, 2026 16:58 Inactive

kmurugulla force-pushed the medialib-quality branch from fd71c87 to 5bc18fa Compare July 8, 2026 16:59

aem-code-sync Bot temporarily deployed to medialib-quality July 8, 2026 16:59 Inactive

kmurugulla and others added 11 commits July 11, 2026 19:25

fix: use daFetch.initIms for plugin mode preview auth

b0f5c10

fix: clarify author role requirement for medialog access

5537a7d

feat: add user-friendly validation error messages

e1abe64

refactor: centralize hardcoded user messages

51870cb

fix: ensure consistent dark mode backgrounds

c41165d

refactor: use HTTP status code numbers for consistency with codebase

5bbc395

refactor: rename t() to getMessage() for clarity

3c3f042

refactor: replace custom CSS variables with inline light-dark() for c…

5c247e6

…onsistent dark mode

refactor: remove misleading CSS comment about variable inheritance

9a1b48c

refactor: optimize full index memory usage with field projection and …

a361f06

…remove redundant auditlog fetch

kmurugulla force-pushed the medialib-quality branch from 5bc18fa to a361f06 Compare July 11, 2026 23:26

aem-code-sync Bot deployed to medialib-quality July 11, 2026 23:26 View deployment

kmurugulla requested a review from mhaack July 11, 2026 23:27

Uh oh!

Conversation

kmurugulla commented Jul 7, 2026

Uh oh!

aem-code-sync Bot commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Current Implementation (using nx)

Code flow:

nx2 Limitation

Security Note

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kmurugulla Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

aem-code-sync Bot commented Jul 7, 2026 •

edited

Loading

kmurugulla Jul 9, 2026 •

edited

Loading