Regression in 26.1.0: Job Details Tests iframe subresource requests now return WWW-Authenticate, triggering browser login popup

Summary

After upgrading to 26.1.0, opening a job details page can trigger a browser basic-auth login dialog. This appears to happen when the Tests iframe (or similar artifact-backed iframe content) loads relative JS/CSS/assets under /files/... and those requests are unauthenticated.

Environment

Basic Details:

• Go Server Version: 26.1.0

Additional Details (if relevant):

• Browser vendor/version: Chrome

Steps to Reproduce

1. Open job details page for a job with test output index.html (ensure this html file references a relative file e.g. <script src="foo.js" /> .
2. Tests iframe content loads and requests relative assets from /go/files/.... (foo.js)
3. Some /files/... requests (foo.js) are treated as unauthenticated (no JSESSIONID on those requests in this context).
4. Server responds with 401 and WWW-Authenticate: Basic realm="GoCD".
5. Browser shows a native login prompt dialog.

Actual Results

Browser presenting basic auth challenge dialog upon loading the job details

Expected Results

Loading job details (including Tests iframe/artifact-backed content) should not trigger a browser basic-auth popup.

Suspected regression

In 25.4.0..26.1.0, auth handling for /files/** changed in AuthorizeFilterChain:

• commit: 8be3a674c3 server/src/main/java/com/thoughtworks/go/server/newsecurity/filterchains/AuthorizeFilterChain.java
• /files/** now uses BasicAuthenticationWithChallengeFailureResponseHandler (adds WWW-Authenticate) rather than falling through generic browser redirect behaviour.

Other notes

When the job details page loads this template is included: https://github.com/gocd/gocd/blob/4d86c688ef8689b1e0b9789284b3dedce6104ac6/server/src/main/webapp/WEB-INF/vm/build_detail/_tests.ftlh, though it's unclear to me why this needs to happen on the page load for the console tab.

Ultimately it's this i-frame that is causing the issue becuase it has a sandbox set that doesn't include allow-same-origin which would allow the jsessionid cookie to be attached to the async requests. I am not sure this would be desirable behaviour either, though cannot think of an immediate risk as it will only be the go server that gets this cookie (same origin).