You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have tinyauth configured on tinyauth.domain.com. I use it to protect domain.com, which correctly redirects to tinyauth, but then successful authentication leads to tinyauth.domain.com instead of the root domain. This does not happen with any subdomains.
Happens since 5.1.0 and still on 5.1.1, but not on 5.0.7.
This looks like a regression introduced by PR #950, which refactored how redirect validation works. The root cause is in the isRedirectSafe() function [1], which validates redirects in two phases:
Phase 1 — checks if the redirect URI exactly matches the AppURL. For your case, domain.com ≠ tinyauth.domain.com, so this fails.
Phase 2 — if subdomains are enabled, checks if the redirect hostname ends with ".{CookieDomain}" (note the dot prefix). Since GetCookieDomain() strips the leftmost label from tinyauth.domain.com to produce domain.com[2], the check becomes: does "domain.com" end with ".domain.com"? It doesn't — because domain.comis the cookie domain, not a subdomain of it.
So the root domain gets rejected by both phases, and the frontend falls back to redirecting to /logout[3].
Before v5.1.0, redirect validation used a pre-built TrustedDomains list that likely included both the AppURL host and the cookie domain, which is why v5.0.7 worked correctly.
Regarding issue #937 — that's actually about trailing slashes in TINYAUTH_APPURL causing double-slash URLs [4], so it's a separate issue from what you're experiencing.
Hello @mmolitor87 this is a bit of weird edge-case that I haven't considered. In v5.1.0, we made the validation engine much more strict for input URLs to avoid any sort of bypass. Tinyauth is meant to protect stuff on the same part of the domain as itself (so under .example.com) but I guess we could also add an exception for the parent domain. Authentication is working fine though right?
If authentication is working, would it be too much of an inconvenience to wait maybe a week for a patch? I don't want to create a new release for every bug (except the ones impacting functionality like in v5.1.1) so I would like to wait a bit in case there are other issues.
For what it's worth, my small setup is exactly the same (redirect to the root domain) and I'm running into the same bug. Thanks for looking into it though!
@steveiliop56 Authentication works fine. I can wait for it to be bundled with something else. It is simply annoying, since I have homepage on the root domain protected by tinyauth.
I'm hitting what looks like the same underlying bug, but with a slightly different trigger: subdomain protecting another subdomain, with TOTP enabled, not root domain.
Setup
Tinyauth: auth.example.com (also a subdomain, not root domain)
Protected app: app.example.com (a self-hosted app using header-based remote-user auth, via remote_user_guard)
Correctly redirected to https://auth.example.com/login?redirect_uri=https://app.example.com/
Submit username/password → 200 "TOTP required", correct session cookie set
Redirected to /totp?redirect_uri=https%3A%2F%2Fapp.example.com%2F (redirect_uri correctly preserved)
Submit TOTP code (once, no double submit) → POST /api/user/totp returns 200 "Login successful" with a valid new session cookie
Immediately after, the frontend navigates to GET /logout instead of following the redirect_uri / showing the continue screen
Confirmed via HAR that redirect_uri is present and correct at every single step up to and including the TOTP page, and the session cookie set on the successful TOTP response looks valid (correct Domain, SameSite=Lax, HttpOnly, proper expiry). The jump to /logout happens client-side (referer on the /logout request is the /totp?redirect_uri=... page), so it looks like a frontend routing issue after the TOTP step specifically, separate from (or compounding) the root-domain case described above.
Note: the protected app itself isn't relevant to the bug — the issue is entirely within the tinyauth login/TOTP → redirect flow, before any request reaches the protected app.
Happy to share the full HAR trace (redacted) if useful.
@erwinkramer you replied to Fla95100 whose issue is basically the login_for parameter missing. If you use another proxy then you don't have the same issue with. Where you trying to access domain.com with Tinyauth on example.domain.com?
@steveiliop56 see below, I think there is some hint where it mentions "No matching container found for domain" or " Failed to validate redirect URI [..] "scheme mismatch"" (I'm doing https to http redirect).
Tested now. Same result as the previous beta, no change.
Still stuck at /continue: flow reaches /continue?redirect_uri=https%3A%2F%2Fapp.example.com%2F correctly after a successful TOTP submission (no more incorrect jump to /logout, that part stays fixed), but the automatic redirect to the target redirect_uri still never fires. No further navigation, no error.
Network tab: every request on the /continue page returns a clean 200, including two back-to-back calls each to /api/context/app and /api/context/user (fired twice in a row, ~70-120ms each) — not sure if that duplication is expected or itself a symptom, but flagging it in case it's relevant.
Console: checked with network/XHR noise filtered out, leaving only Errors/Warnings — nothing shown. The failure is completely silent client-side, nothing thrown that would explain why the redirect logic doesn't execute.
Here you have it. This is the screen I'm stuck after logging in. To come back to the app I need to manually write the address in the search bar. I also included the network tab from developer option just in case, but the console tab does not show anything.
Let me know if there is any screen in particular you want to see.
Yeah that's not the continue screen, it's redirecting you to the logout which means that the redirect URL is not trusted. Can you please share your logs while trying to login with TINYAUTH_LOG_LEVEL=debug?
Seems like similar behaviour for me too, after upgrading to 5.1.0.
The flow I'm seeing seems to match what is described here.
GET /login?redirect_uri=...
↓
POST /api/user/login → 200 + Set-Cookie
↓
GET /totp??redirect_uri=...
↓
POST /api/user/totp → 200 + Set-Cookie
↓
Frontend JS (index-*.js)
↓
GET /logout (INSTEAD OF A REDIRECT)
My setup used to work fine just before the upgrade (nginx, subdomains).
The session is valid. Opening the protected application in another tab succeeds without another login. The only failure is that the SPA navigates to /logout instead of the original redirect_uri.
Activity
dosubot commentedon Jul 17, 2026
Hi @mmolitor87! I'm Dosu and I'm helping the Tinyauth team.
This looks like a regression introduced by PR #950, which refactored how redirect validation works. The root cause is in the
isRedirectSafe()function [1], which validates redirects in two phases:domain.com≠tinyauth.domain.com, so this fails.".{CookieDomain}"(note the dot prefix). SinceGetCookieDomain()strips the leftmost label fromtinyauth.domain.comto producedomain.com[2], the check becomes: does"domain.com"end with".domain.com"? It doesn't — becausedomain.comis the cookie domain, not a subdomain of it.So the root domain gets rejected by both phases, and the frontend falls back to redirecting to
/logout[3].Before v5.1.0, redirect validation used a pre-built
TrustedDomainslist that likely included both the AppURL host and the cookie domain, which is why v5.0.7 worked correctly.Regarding issue #937 — that's actually about trailing slashes in
TINYAUTH_APPURLcausing double-slash URLs [4], so it's a separate issue from what you're experiencing.To reply, just mention @dosu.
Docs are dead. Just use Dosu.
steveiliop56 commentedon Jul 17, 2026
Hello @mmolitor87 this is a bit of weird edge-case that I haven't considered. In v5.1.0, we made the validation engine much more strict for input URLs to avoid any sort of bypass. Tinyauth is meant to protect stuff on the same part of the domain as itself (so under
.example.com) but I guess we could also add an exception for the parent domain. Authentication is working fine though right?If authentication is working, would it be too much of an inconvenience to wait maybe a week for a patch? I don't want to create a new release for every bug (except the ones impacting functionality like in v5.1.1) so I would like to wait a bit in case there are other issues.
Nomar383 commentedon Jul 17, 2026
For what it's worth, my small setup is exactly the same (redirect to the root domain) and I'm running into the same bug. Thanks for looking into it though!
mmolitor87 commentedon Jul 18, 2026
@steveiliop56 Authentication works fine. I can wait for it to be bundled with something else. It is simply annoying, since I have homepage on the root domain protected by tinyauth.
Fla95100 commentedon Jul 18, 2026
I'm hitting what looks like the same underlying bug, but with a slightly different trigger: subdomain protecting another subdomain, with TOTP enabled, not root domain.
Setup
auth.example.com(also a subdomain, not root domain)app.example.com(a self-hosted app using header-based remote-user auth, viaremote_user_guard)auth_request+/api/auth/nginx), behind CloudflareCOOKIE_DOMAIN=example.com,APP_URL=https://auth.example.comReproduction
app.example.comwhile unauthenticatedhttps://auth.example.com/login?redirect_uri=https://app.example.com/200 "TOTP required", correct session cookie set/totp?redirect_uri=https%3A%2F%2Fapp.example.com%2F(redirect_uri correctly preserved)POST /api/user/totpreturns200 "Login successful"with a valid new session cookieGET /logoutinstead of following theredirect_uri/ showing the continue screenConfirmed via HAR that
redirect_uriis present and correct at every single step up to and including the TOTP page, and the session cookie set on the successful TOTP response looks valid (correctDomain,SameSite=Lax,HttpOnly, proper expiry). The jump to/logouthappens client-side (referer on the/logoutrequest is the/totp?redirect_uri=...page), so it looks like a frontend routing issue after the TOTP step specifically, separate from (or compounding) the root-domain case described above.Note: the protected app itself isn't relevant to the bug — the issue is entirely within the tinyauth login/TOTP → redirect flow, before any request reaches the protected app.
Happy to share the full HAR trace (redacted) if useful.
erwinkramer commentedon Jul 18, 2026
@Fla95100 similar issue here as u have. I'm going from https to http subdomain though, but yes this worked before
steveiliop56 commentedon Jul 18, 2026
@Nomar383 @erwinkramer relevant issue #1023
erwinkramer commentedon Jul 18, 2026
@steveiliop56 for me it's not in context of nginx, are you sure that solves it for others? Like caddy.
steveiliop56 commentedon Jul 18, 2026
@erwinkramer you replied to Fla95100 whose issue is basically the
login_forparameter missing. If you use another proxy then you don't have the same issue with. Where you trying to accessdomain.comwith Tinyauth onexample.domain.com?erwinkramer commentedon Jul 18, 2026
@steveiliop56 yeah sorry for the confusion, only the first part is similar, so I have:
In a regular OAuth setup with caddy, tinyauth an GitHub login.
steveiliop56 commentedon Jul 18, 2026
Hmm, can you please share your logs with
TINYAUTH_LOG_LEVEL=debugwhile trying to login.erwinkramer commentedon Jul 18, 2026
@steveiliop56 see below, I think there is some hint where it mentions "No matching container found for domain" or " Failed to validate redirect URI [..] "scheme mismatch"" (I'm doing https to http redirect).
14 remaining items
Fla95100 commentedon Jul 18, 2026
Tested now. Same result as the previous beta, no change.
Still stuck at /continue: flow reaches /continue?redirect_uri=https%3A%2F%2Fapp.example.com%2F correctly after a successful TOTP submission (no more incorrect jump to /logout, that part stays fixed), but the automatic redirect to the target redirect_uri still never fires. No further navigation, no error.
Network tab: every request on the /continue page returns a clean 200, including two back-to-back calls each to /api/context/app and /api/context/user (fired twice in a row, ~70-120ms each) — not sure if that duplication is expected or itself a symptom, but flagging it in case it's relevant.
Console: checked with network/XHR noise filtered out, leaving only Errors/Warnings — nothing shown. The failure is completely silent client-side, nothing thrown that would explain why the redirect logic doesn't execute.
steveiliop56 commentedon Jul 18, 2026
@Fla95100 can you please share a screenshot?
Fla95100 commentedon Jul 18, 2026
For the console?
steveiliop56 commentedon Jul 18, 2026
No, of your web browser.
Fla95100 commentedon Jul 18, 2026
Here you have it. This is the screen I'm stuck after logging in. To come back to the app I need to manually write the address in the search bar. I also included the network tab from developer option just in case, but the console tab does not show anything.

Let me know if there is any screen in particular you want to see.
steveiliop56 commentedon Jul 18, 2026
Yeah that's not the continue screen, it's redirecting you to the logout which means that the redirect URL is not trusted. Can you please share your logs while trying to login with
TINYAUTH_LOG_LEVEL=debug?Fla95100 commentedon Jul 18, 2026
2026-07-18T23:00:44Z DBG internal/controller/user_controller.go:73 > Login attempt stream=app username=flavio
2026-07-18T23:00:45Z DBG internal/controller/user_controller.go:136 > TOTP required for user, creating pending TOTP session stream=app username=flavio
2026-07-18T23:00:45Z INF internal/middleware/zerolog_middleware.go:74 > Request address=172.28.0.1:36160 client_ip=172.28.0.1 latency=103.433862ms method=POST path=/api/user/login status=200 stream=http
2026-07-18T23:00:45Z DBG internal/middleware/context_middleware.go:85 > Authenticated user flavio via session cookie stream=app
2026-07-18T23:00:45Z INF internal/middleware/zerolog_middleware.go:74 > Request address=172.28.0.1:49942 client_ip=172.28.0.1 latency="34.842µs" method=GET path=/api/context/app status=200 stream=http
2026-07-18T23:00:45Z DBG internal/middleware/context_middleware.go:85 > Authenticated user flavio via session cookie stream=app
2026-07-18T23:00:45Z INF internal/middleware/zerolog_middleware.go:74 > Request address=172.28.0.1:49952 client_ip=172.28.0.1 latency="399.052µs" method=GET path=/api/context/user status=200 stream=http
2026-07-18T23:00:46Z DBG internal/middleware/context_middleware.go:85 > Authenticated user flavio via session cookie stream=app
2026-07-18T23:00:46Z DBG internal/controller/user_controller.go:315 > TOTP verification attempt stream=app username=flavio
2026-07-18T23:00:46Z INF internal/controller/user_controller.go:395 > TOTP verification successful, login complete stream=app username=flavio
2026-07-18T23:00:46Z INF internal/middleware/zerolog_middleware.go:74 > Request address=172.28.0.1:49968 client_ip=172.28.0.1 latency=26.524515ms method=POST path=/api/user/totp status=200 stream=http
2026-07-18T23:00:47Z DBG internal/middleware/context_middleware.go:85 > Authenticated user flavio via session cookie stream=app
2026-07-18T23:00:47Z INF internal/middleware/zerolog_middleware.go:74 > Request address=172.28.0.1:49982 client_ip=172.28.0.1 latency="86.193µs" method=GET path=/api/context/app status=200 stream=http
2026-07-18T23:00:47Z DBG internal/middleware/context_middleware.go:85 > Authenticated user flavio via session cookie stream=app
2026-07-18T23:00:47Z INF internal/middleware/zerolog_middleware.go:74 > Request address=172.28.0.1:49994 client_ip=172.28.0.1 latency="43.783µs" method=GET path=/api/context/user status=200 stream=http
2026-07-18T23:00:53Z DBG internal/middleware/zerolog_middleware.go:77 > Request address=127.0.0.1:56754 client_ip=127.0.0.1 latency="22.033µs" method=GET path=/api/healthz status=200 stream=http
mchatzi commentedon Jul 19, 2026
Seems like similar behaviour for me too, after upgrading to 5.1.0.
The flow I'm seeing seems to match what is described here.
My setup used to work fine just before the upgrade (nginx, subdomains).
The session is valid. Opening the protected application in another tab succeeds without another login. The only failure is that the SPA navigates to /logout instead of the original redirect_uri.
Super nice app btw, thank you so much!
erwinkramer commentedon Jul 19, 2026
@steveiliop56
This works for me now on beta 2. Redirecting from https to http works again like it used to. Thanks
steveiliop56 commentedon Jul 19, 2026
@mchatzi @Fla95100 I can replicate with 2FA, working on a fix.
mmolitor87 commentedon Jul 19, 2026
@steveiliop56 I can confirm v5.1.2-beta.1 works! Thank you so much!
steveiliop56 commentedon Jul 19, 2026
@mchatzi @Fla95100 please test
v5.1.2-beta.3.Fla95100 commentedon Jul 19, 2026
It works!! Now after login I am brought to a redirect page and then to the app.
Thanks!
steveiliop56 commentedon Jul 20, 2026
Perfect!