[drkjc]

Changes

• Example servers listen on 127.0.0.1 by default, so only the local machine can reach them. Set HOST=0.0.0.0 to accept connections from other machines.
• Docker images set HOST=0.0.0.0 so the server is reachable inside the container, and Docker Compose publishes each port on 127.0.0.1 only.
• The .NET sidecar builds ASPNETCORE_URLS from HOST instead of hard-coding 0.0.0.0.
• The READMEs run the PHP built-in server on 127.0.0.1 and document HOST.
• The node example only allows CORS requests from the web-next origin (http://localhost:3000), overridable with CORS_ORIGIN. The web-next README explains setting it when running on a custom port.
• web-next uses next 15.5.28 and follow-redirects 1.16.1 to clear high and critical npm audit advisories.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[datadog-spreedly]

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 1273643 | Docs | Give us feedback!}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Samy-O7]

Approving. Checked at fdcad8e:

• All seven sidecars listen on 127.0.0.1 by default, with HOST to override: node-ts, python, ruby, go, java and dotnet in code, and php through the php -S 127.0.0.1:3022 commands in both READMEs.
• The Dockerfiles set HOST=0.0.0.0 (php's CMD uses 0.0.0.0 directly), so the containers stay reachable, and Compose publishes every port, including the test fake API on 3099, on 127.0.0.1 only.
• client/web-next needs no change: its checkpoint and event calls come from client components in the browser, so it never relays requests to a sidecar.

Optional, not blocking: node-ts uses cors(), which allows any origin, so a web page open in the developer's browser can still call the sidecar on localhost. Limiting it to the web-next origin (http://localhost:3000 by default, overridable with an env var) would close that, and the server/README line about allowing any origin could then describe the restricted setup.

[drkjc]

@Samy-O7 Added in 91dd5f0: node-ts only allows CORS from http://localhost:3000, overridable with CORS_ORIGIN (listed in node-ts/.env.example). The server README now explains when to set it. I also removed app.options("*", cors()), since app.use(cors(...)) already handles preflights.

[Samy-O7]

Re-approving at 91dd5f0. I checked the CORS commit by running node-ts against server/tests/fake-composer-api.mjs:

• Preflights now get Access-Control-Allow-Origin set to the configured origin (http://localhost:3000 by default) instead of *, so other origins can't read responses. CORS_ORIGIN overrides it.
• JSON checkpoint and event calls from the web-next origin still reach the API.
• Cross-site text/plain, urlencoded and multipart posts (the ones browsers send without a preflight) reach nothing, as before: /checkpoint returns 400 and /event sends nothing.
• Dropping app.options("*", cors()) is fine, since app.use(cors(...)) already answers preflights.

Optional nit: client/web-next/README.md suggests npm run dev -- --port <port>. A line there about setting CORS_ORIGIN in server/node-ts/.env would save a CORS error for anyone who changes the port.

[Samy-O7]

Re-approving at 1273643. Checked the two new commits:

• The web-next README now says to set CORS_ORIGIN in server/node-ts/.env when running on another port, which matches how node-ts reads it.
• In client/web-next/package-lock.json, only next, @next/env, the nine @next/swc-* binaries and follow-redirects change. Every integrity hash matches the registry, and next 15.5.28 was published with provenance.
• The web-next check now passes npm audit --omit=dev --audit-level=high (only the two uuid moderates from @dodgeball/trust-sdk-client remain) and builds on Next.js 15.5.28.

For the record, web-next wasn't exposed to either of today's Next.js advisories: it has no Server Actions and already resolved sharp 0.35.5.