SLP_Software/slp-modular-cms
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Wiki Activity

Warns against copying the reference project's nginx Sentry tunnel

Browse Source 
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.
This commit is contained in:
Sluijsens
2026-07-29 13:43:33 +02:00
parent 50c1a5106d
commit c438ec8b1d
2 changed files with 19 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md
+9
View File
@@ -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