Sourcepoint privacy manager assets 404 through first-party proxy

[ChristianPavilonis]

Description

Sourcepoint first-party proxying can load the wrapper script and return a message campaign, but the privacy manager iframe may fail to render because Sourcepoint HTML apps reference root-relative assets such as /PrivacyManagerUS...css, /polyfills...js, and /PrivacyManagerUS...js.

When the HTML is served through Trusted Server at /integrations/sourcepoint/cdn/us_pm/index.html, those root-relative asset URLs resolve against the publisher origin root instead of the Sourcepoint proxy prefix. In local testing this caused the iframe assets to return 404 and prevented the Sourcepoint notice from rendering.

There is a second debugging problem: Sourcepoint consent/local state can suppress message creation or leave the created sp_message_container_* hidden, which makes it hard to verify proxy behavior locally after the first load.

Expected behavior

• Proxied Sourcepoint HTML should load its CSS/JS assets through /integrations/sourcepoint/cdn/....
• Local debugging should have an explicit opt-in way to clear Sourcepoint state and force any created banner container visible.

Observed behavior

• Sourcepoint wrapper and API calls returned 200.
• The Sourcepoint iframe was created, but iframe assets requested root paths and returned 404.
• After asset rewriting was fixed locally, Sourcepoint could still hide/suppress the banner based on existing local consent state.

Proposed fix

• Rewrite root-relative src / href attributes in Sourcepoint HTML responses to include /integrations/sourcepoint/cdn.
• Add debug-only Sourcepoint configuration flags for local testing:
  • clear Sourcepoint state on load
  • force inserted sp_message_container_* elements visible