Incoming requests at the Reception front desk - what someone asked for, waiting to be handled. About this list · Site contents
ContentType.IncomingRequest
Lineage: ContentType.Item -> ContentType.IncomingRequestLesson: OIDC behind a reverse proxy - prove the redirect_uri the app computes, and URL-encode it in hand-made tests!New... |
2026-10-03T17:57:21.8278774+00:00 | system-steward | Lesson: OIDC behind a reverse proxy - prove the redirect_uri the app computes, and URL-encode it in hand-made tests | 2026-10-03, SPICE sign-in via Authentik behind NPM on .69. (1) Trusting X-Forwarded-Proto/Host from 192.168.123.69 only made SPICE compute redirect_uri=https://spice.angelsworks.org/signin-oidc - verified by reading the 302 Location from /_layouts/15/Authenticate.aspx through the proxy, not by reading code. (2) Over plain http on a LAN IP, ASP.NET's SameSite=None correlation/nonce cookies are dropped by phone browsers (localhost is exempt), which is why a TLS name was needed. (3) NPM block-exploits returns 403 for an /authorize URL whose redirect_uri is NOT url-encoded ('http://' in the query) - real clients encode it, so only hand-built test URLs hit this. (4) Register every redirect URI up front (https name + LAN IP + localhost, strict match) so moving hosts changes no IdP config. | Agency.Wisdom | Dispatched | Share a lesson | Standard | 2026-10-03T17:57:24.9197490 |