u/GonnaBeAGoodDayTater

Hi all - looking for guidance on how a non-browser native client should authenticate against a Pangolin SSO protected resource. This setup worked for well over a month and stopped at some point after May 11.

(note: I used AI to clean up my notes and make them more coherent)

Setup

- Pangolin 1.18.4 (also reproduced on 1.17.0), Gerbil 1.4.0, Traefik v3.6, single Newt site

- Resource: OpenWebUI at app.example.com with sso = true, no other auth methods (password / pincode / whitelist / header / access token are unset)

- Client: Conduit (official iOS client for OpenWebUI), a Flutter app - Dart HTTP client for API calls + WKWebView for the SSO step

Timeline

- February → May 11: Conduit worked. Traefik access logs show its Dart HTTP client successfully reaching the OpenWebUI backend service across that whole window - hundreds of 200s on /api/v1/... endpoints, no cookies visible in the logs.

- Gap of ~9 days where I didn't use Conduit because I was on vacation.

- May 20 onward: completely broken. Same Dart client, same iOS device, but every request now stops at Pangolin's auth page - zero traffic reaches the OpenWebUI backend service.

- Closest discrete event in the gap: the Pangolin container restarted on May 14. No image version change, no config file edits, no DB migrations. I cannot definitively identify what changed.

Current behavior

- Conduit opens a WKWebView to perform login. The user successfully signs in on proxy.example.com - I can see a valid user session in the session table and dozens of short-lived resourceSessions entries (isRequestToken=1, sessionLength 30000) being issued for the resource.

- The webview then loops on /auth/resource/<guid>?redirect=https://app.example.com/api/..., never reaching the OpenWebUI backend.

- Conduit surfaces: "SSO authentication failed - Invalid token or insufficient permissions"

What the traefik access log shows

The webview makes a CORS preflight OPTIONS https://app.example.com/api/config. Pangolin's middleware responds with a 302 to https://proxy.example.com/auth/resource/<guid>?redirect=.... The webview follows the

302 preserving the OPTIONS method. The Next.js dashboard at that path returns 400 with no Access-Control-Allow-Origin, which breaks the preflight, and the browser never makes the real request. This loops forever.

What I tried

- Recreating the resource from scratch - same behavior

- Upgrading the whole stack (Pangolin 1.17 → 1.18.4, Gerbil 1.3.1 → 1.4.0) - same behavior

- Downgrading OpenWebUI to the older version that was running when this last worked - same behavior, confirming the block is upstream of OpenWebUI

- Adding https://app.example.com to server.cors.origins in config.yml and restarting Pangolin - no effect, because that setting governs the API server, not the Next.js auth page that's actually returning the 400

Question

 Is there a supported way for Conduit (or any native client whose SSO step is a WKWebView) to get through a resource gated by Pangolin SSO? Specifically:

 1. Should the SSO middleware respond directly to OPTIONS preflights with CORS headers instead of redirecting them? If so, is there a config to enable that, or is it a feature request?

 2. Are Resource Access Tokens or Resource Header Auth the intended path here? If so, how do you configure a client that only sends Authorization: Bearer <OpenWebUI-token> to also include a Pangolin token/header - Conduit doesn't expose a custom-headers field as far as I can tell.

3. Did anything change in Pangolin's SSO middleware behavior between an early-April 1.17.0 build and now that would explain a working setup quietly breaking on a container restart?

Happy to share more log excerpts or DB output if useful. Thanks!