NMS-20180: Fix various menu-related issues after NMS-20174 Review

[synqotik]

Fix various issues found in PR review for NMS-20174 (PR #8758) ("Fix Menubar/SideMenu issues in Firefox and Safari on JSP pages").

There were 9 different items. 5 are fixed here. 4 have been deferred as they represent more work or tradeoffs.

Fixed Items

Fix 1 — narrowed anonymous rule: applicationContext-spring-security.xml now grants /ui-components/assets/** instead of /ui-components/**, with a comment explaining why (due to the stray index.html in the dist-menu artifact, NMS-20180). /ui-components/index.html now falls through to the /** → ROLE_USER catch-all, so it 302s to login like any other page.

Fix 3 — comment only: extended the bootstrap.jsp head comment to mark the login-page stylesheet + modulepreload as deliberate cache-warming, cross-referencing the anonymous rule it depends on.

Fix 4 — test gap: added expect(event.defaultPrevented).toBe(false) to the "does not cancel navigation for regular items" test.

FIx 7 — WebappIT smoke tests (three new tests): anonymous GET of the menu JS/CSS returns 200 with the right content types; ui-components/index.html requires auth (302, pinning fix 1's narrowing); and login.jsp contains no <script> tag for the menu bundle — with a positive control asserting the preload link is present so the negative assertion stays meaningful.

Fix 9 — locale-safe URL matching (LoginModuleUtils.java:163): toLowerCase() → toLowerCase(Locale.ROOT), with a comment explaining the Turkish dotless-ı problem and added tests.

Deferred Items

These four items were identified while reviewing the NMS-20174 fixes (PR #8758) but deliberately not fixed in NMS-20180. I will open separate tickets to follow up.

1. Vue menu disappeared from nine popup JSPs (documentation / QA spot-check)

What happened. NMS-20174 fix #2 made bootstrap.jsp honor both quiet
mechanisms (the param.quiet include parameter and the Bootstrap.flags("quiet")
request attribute). The PR description only mentions login.jsp, but nine other JSPs
also set the quiet flag and therefore silently lost the Vue menu with that change:

• admin/discovery/add-er.jsp
• admin/discovery/add-ex-url.jsp
• admin/discovery/add-ir.jsp
• admin/discovery/add-specific.jsp
• admin/discovery/add-url.jsp
• admin/userGroupView/users/newPassword.jsp
• graph/forecast.jsp
• graph/nrtg.jsp
• includes/legendInfo-box.jsp

Why it is probably fine. Every one of these is opened via window.open as a
popup/utility window. Losing the menu there is almost certainly the intended
rendering — and the pre-fix behavior (menu app executing in a popup that had asked
for quiet mode) is a plausible source of the original "menus overlapping content"
symptom.

---

2. Cache-buster stats the menu bundle files on every legacy page render

What happens today. includes/bootstrap.jsp computes the ?v= cache-buster for
the menu bundle by calling application.getRealPath(...) + File.lastModified()
for both index.js and index.css on every JSP page render (two filesystem
stats per request). The load-assets.jsp precedent it mirrors reads a cached
AssetLocator.lastModified() instead.

Suggested fix. Memoize the computed version in a ServletContext attribute,
keyed on (or invalidated by) the files' mtimes, or re-checked on a short TTL.

Tradeoffs / why it was deferred.

• Two stats per render is noise next to JSP rendering cost; the OS caches the inode.
  There is no observed performance problem.
• A naive memoization (compute once, cache forever) breaks the hot-copy developer
  workflow (build-and-copy.sh, ui/CLAUDE.md instructions): newly copied bundles
  would keep serving the stale ?v= until a webapp restart. A correct fix needs
  mtime-keyed or TTL-based invalidation — more code for marginal benefit.
• If item 3 below (content-hashed filenames) is done, this entire code block is
  deleted anyway. Fixing this separately is only worthwhile if content-hashing is
  rejected or slips.

Action: will consider folding it into the content-hashing work if/when we proceed with that./

---

3. Content-hashed filenames for the menu bundle (replace ?v=<mtime>)

What happens today. The menu bundle is built with fixed filenames
(ui/vite.config.menu.ts → assets/index.js, assets/index.css) because
bootstrap.jsp hardcodes the URLs. Cache correctness relies on a ?v=<deployed file mtime> query parameter appended by bootstrap.jsp (added in NMS-20174 fix #6).

Why ?v= is not durable.

1. In-place overwrite skew (the core problem).
2. Per-node divergence.
3. Second-class caching.

Suggested fix.

Leaving out details, but adding a content hash to all filenames.

Costs / risks.

• JSP + Java + Vite config + assembly all change together; needs its own Playwright
  re-verification
• Manifest resolution becomes a runtime dependency of every legacy page: a missing
  or unreadable manifest must fail loudly with a sane fallback, or the menu breaks.
• Dev hot-copy workflow changes: stale hashed files accumulate in the target
  directory (already true for the main SPA — ui/CLAUDE.md documents the occasional
  rm assets/*.*), and the manifest must be copied along with the assets.
• Aligns the menu app with the main SPA, which already uses Vite's default hashed
  filenames.

Action: Will open a separate ticket to do the full content-hash + manifest change, targeted at the next
major release (Horizon 37).

4. Root fix for REST/API requests polluting the Spring Security request cache

Omitting details, but this is a larger effort as part of fixing OpenNMSAuthSuccessHandler and HttpSessionRequestCache to not saved assets in the cache, and to more properly handle redirects.

Action: Will open a separate ticket to do a comprehensive fix in Horizon 37.

External References

• Jira (Issue Tracker): https://opennms.atlassian.net/browse/NMS-20180