Goal
Add a regression integration test that specifically validates the cross-site URL map isolation behavior broken by #35345 and fixed by #35621.
The test must fail when the bad fix from #35345 is re-applied (two-step fallback with no conhost filter), and pass when the correct single-pass query with +(conhost:<site> OR conhost:SYSTEM_HOST) is in place.
Background
PR #35345 introduced a two-step fallback in URLMapAPIImpl.getContentlet():
- First query with host restriction:
+(conhost:brandA.id OR conhost:SYSTEM_HOST) → empty
- Second query without any host filter → returns a different site's content on the requesting site's page
This caused a production incident on a multi-brand installation where several sites sharing a Content Type and URL map pattern rendered the wrong site's content on URL-mapped pages.
PR #35621 reverted #35345, restoring the single-pass query with the conhost filter always in place.
See: #35616 for full root cause analysis.
What the Test Must Cover
Scenario 1 — Pure cross-site bleed (negative test)
- Site A and Site B are separate sites sharing a Content Type with a URL map pattern
- Site B publishes content with slug
heat-pumps-xxx
- Site A has no content for that slug
- When Site A requests
/brand-map-xxx/heat-pumps-xxx, the result must be empty
Fails with the bad fix (second query returns Site B's content).
Passes with the correct fix (single-pass query filters by conhost:siteA.id).
Scenario 2 — Positive + negative (companion test)
- Site A publishes
slug-a, Site B publishes slug-b
- Site A's request for
slug-a resolves to Site A's content
- Site A's request for
slug-b returns empty
Current Status
A first draft of both tests exists in URLMapAPIImplTest.java but both fail even with the correct production code in place. The failure is caused by a test setup bug: TestDataUtils.getNewsContent + getNewsLikeContentType with site = siteA creates a content type with a HostFolderField scoped to Site A, and when Site B creates content using this type, the content ends up indexed with conhost = siteA.id instead of conhost = siteB.id in Elasticsearch.
The test setup needs to be fixed so that:
- Site B's content is reliably indexed with
conhost = siteB.id
- The
conhost filter in the URL map query correctly excludes it when Site A requests
Acceptance Criteria
Related
Goal
Add a regression integration test that specifically validates the cross-site URL map isolation behavior broken by #35345 and fixed by #35621.
The test must fail when the bad fix from #35345 is re-applied (two-step fallback with no
conhostfilter), and pass when the correct single-pass query with+(conhost:<site> OR conhost:SYSTEM_HOST)is in place.Background
PR #35345 introduced a two-step fallback in
URLMapAPIImpl.getContentlet():+(conhost:brandA.id OR conhost:SYSTEM_HOST)→ emptyThis caused a production incident on a multi-brand installation where several sites sharing a Content Type and URL map pattern rendered the wrong site's content on URL-mapped pages.
PR #35621 reverted #35345, restoring the single-pass query with the
conhostfilter always in place.See: #35616 for full root cause analysis.
What the Test Must Cover
Scenario 1 — Pure cross-site bleed (negative test)
heat-pumps-xxx/brand-map-xxx/heat-pumps-xxx, the result must be emptyFails with the bad fix (second query returns Site B's content).
Passes with the correct fix (single-pass query filters by
conhost:siteA.id).Scenario 2 — Positive + negative (companion test)
slug-a, Site B publishesslug-bslug-aresolves to Site A's contentslug-breturns emptyCurrent Status
A first draft of both tests exists in
URLMapAPIImplTest.javabut both fail even with the correct production code in place. The failure is caused by a test setup bug:TestDataUtils.getNewsContent+getNewsLikeContentTypewithsite = siteAcreates a content type with aHostFolderFieldscoped to Site A, and when Site B creates content using this type, the content ends up indexed withconhost = siteA.idinstead ofconhost = siteB.idin Elasticsearch.The test setup needs to be fixed so that:
conhost = siteB.idconhostfilter in the URL map query correctly excludes it when Site A requestsAcceptance Criteria
Related