From c438ec8b1df3ba37c2707ae7aabb18761e1e5855 Mon Sep 17 00:00:00 2001 From: Sluijsens Date: Wed, 29 Jul 2026 13:43:33 +0200 Subject: [PATCH] Warns against copying the reference project's nginx Sentry tunnel The backend already serves /sentry-tunnel itself with its own rate limit, payload cap, and DSN-derived destination - exactly what that nginx block exists to avoid needing. Proxying the same path at nginx intercepts it first and silently drops all three protections. --- aidlc-docs/features/gitea-deployment-workflow/audit.md | 10 ++++++++++ .../operations/deployment/deployment-instructions.md | 9 +++++++++ 2 files changed, 19 insertions(+) diff --git a/aidlc-docs/features/gitea-deployment-workflow/audit.md b/aidlc-docs/features/gitea-deployment-workflow/audit.md index 71a3975..7d9a0d4 100644 --- a/aidlc-docs/features/gitea-deployment-workflow/audit.md +++ b/aidlc-docs/features/gitea-deployment-workflow/audit.md @@ -1399,3 +1399,13 @@ by Infrastructure Design. U5 carries REF-U3-01's Umami origin gate plus FR-21 an **Context**: OPERATIONS — Deployment Setup, reverse-proxy topology corrected across Operations and Construction docs --- +## Deployment Setup — nginx Sentry Tunnel Block Shadows the Backend's Own Tunnel + +**Timestamp**: 2026-07-29T00:50:00Z + +**User Input**: Shared their actual proxy-Pi nginx config, which includes a `location /sentry-tunnel { proxy_pass https://o4511795618185216.ingest.de.sentry.io/...; }` block carried over from the reference project, and asked whether it's still needed. + +**AI Response**: "Confirmed this is a real conflict, not just redundancy: SentryTunnelExtensions.cs (U4) already serves /sentry-tunnel on the backend itself, with its own rate limiter, TunnelMaxPayloadBytes cap, and a destination derived dynamically from Observability__SentryDsn. The code's own comment says the reference project's nginx-tunnel approach is exactly what this backend feature was built to avoid. The user's nginx block intercepts the same path before it reaches pi-main, bypassing all three backend protections and hardcoding the Sentry org/project ID as a second place that must be kept in sync with the app config. Recommended removing the nginx block entirely and letting /sentry-tunnel fall through to pi-main like any other request. Added an explicit warning in deployment-instructions.md § 1.7 telling readers not to carry this nginx block over from the reference project." + +**Context**: OPERATIONS — Deployment Setup, real host config revealed the reference project's nginx Sentry-tunnel pattern was carried over unnecessarily and conflicts with this app's own built-in tunnel +--- diff --git a/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md b/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md index 7a8d96a..2698b4c 100644 --- a/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md +++ b/aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md @@ -232,6 +232,15 @@ domain through the proxy Pi to *any* backend (this deployment's domains included § 1.7.2 is what that procedure produced for `slpsoftware.nl` — the worked example, not a separate step. +> **Do not add a `/sentry-tunnel` proxy block on the proxy Pi.** The reference project (a static +> frontend with no backend of its own) had to tunnel through nginx directly to Sentry's ingest URL. +> This application does not need that: `SentryTunnelExtensions.cs` (built in U4) serves +> `/sentry-tunnel` itself, with its own rate limiter, a payload-size cap +> (`Observability:TunnelMaxPayloadBytes`), and a destination derived from `Observability__SentryDsn` +> rather than a hardcoded org/project ID. An nginx-level tunnel block at the same path intercepts +> the request before it ever reaches pi-main, silently bypassing all three of those protections — +> let `/sentry-tunnel` fall through the plain `location /` block like any other request instead. + #### 1.7.1 Adding a New Domain From Scratch (on the proxy Pi) Starting from nothing — no existing server block, no certificate — for a new domain