Cannot login using OIDC (pocket-id), login flow looping

[ppkhoa]

Describe the bug
On login page, after successful authentication with OIDC provider (Pocket ID in this case), dashbrr redirected back to login page (/login) without logging in, no error displayed

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Dashbrr' /login page
2. Click on 'Log in with '
3. Login (callback URL set to /api/auth/callback, /api/auth/oidc/callback does not exist)
4. Redirected back to Dashbrr /login page, no error displayed.

Expected behavior
Successful authentication and dashboard displayed

Desktop (please complete the following information):

• OS: Windows 11
• Browser: Waterfox (Firefox equivalent)
• Version 6.6.8

Additional context
Using develop Docker image, 9f4379451ee7d5afe76c80acc569ba61d64de98f321912c01d9e7bc24b76e027

[ilbarone87]

Same here.
docker environment. Using v.0.3.0 breaks oidc authentication.

[poziel]

Same with me as well, been using Pocket ID version 2.3.0 with Dashbrr version v0.3.0. I've been trying different browser as well, but the bug still persist, so it's not browser related.

[filippobaroni]

Issue still persists on my end with Dashbrr v0.3.0 and Pocket ID 2.8.0.

[notmarek]

Authelia on latest develop docker image - same issue

[v8eta]

Ran into this with authentik and dug into it — the loop is not the OIDC flow itself. The callback succeeds and the session is valid, but on dashboard load GET /api/ui/preferences/collapse returns 401 {"error":"User context not found"}, because OIDC sessions carry no local DB user id. The frontend treats any API 401 as an expired session and redirects to /login, so you bounce login → dashboard → 401 → login forever. That also explains why it started with v0.3.0 (when the collapse-preferences endpoint was added) and why it hits every provider.

You can confirm on your instance by watching the network tab after the callback — the 401 on /api/ui/preferences/collapse is the trigger.

Fix proposed in #114: treat authenticated OIDC sessions as a shared user in getContextUserID instead of failing — the route is already behind the auth middleware, so the 401 was spurious. Running it in production, loop is gone.