[BUG] Safe redirects fail when using private DNS zones without a public suffix #1006

Activity

1. cirogargatagli

   assigned

   steveiliop56

   on Jul 15, 2026
2. cirogargatagli

   added

   bugSomething isn't workingSomething isn't working

   on Jul 15, 2026
3. dosubot commented on Jul 15, 2026

   

   dosubotbot

   on Jul 15, 2026 – with DosuBot

   More actions

   Hi @cirogargatagli! I'm Dosu and I'm helping the Tinyauth team.

   This is a valid bug. The root cause is exactly as you identified — in GetCookieDomain() [1], when the hostname has exactly 2 parts (like tinyauth.home), the function always returns the full hostname unchanged, regardless of whether SubdomainsEnabled is true. The len(parts) == 2 branch short-circuits before any subdomain stripping can happen:

   For tinyauth.home, parts = ["tinyauth", "home"], so len(parts) == 2 triggers immediately, returning tinyauth.home as the cookie domain. Then isRedirectSafe() [2] checks whether redirect targets like app.home end with .tinyauth.home — which they don't — so they're rejected.

   For this to work as expected, the cookie domain should be .home so that app.home, jellyfin.home, etc. all pass the subdomain suffix check. The fix would need to handle the case where a 2-part hostname with subdomains enabled and a private (non-public-suffix) TLD should strip the leftmost label, similar to how 3+-part hostnames are handled.

   There is currently no configuration option to manually override the cookie domain [3] — it's always derived automatically from AppURL. A related discussion about OAuth with private .home domains was raised recently in Discussion #994, and several recent PRs have improved homelab support (PR #710, PR #950, PR #1000), but this specific edge case with 2-part private hostnames wasn't addressed.

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
4. steveiliop56 commented on Jul 15, 2026

   

   steveiliop56

   on Jul 15, 2026

   Member

   More actions

   @cirogargatagli This is expected behavior. Tinyauth is not designed to set cookies for .home, .lan or any TLD. We only allow domains like tinyauth.home to pass the check in case you want your apps to be under app.tinyauth.home. Ideally you would want to have Tinyauth under tinyauth.foo.home and your app under app.foo.home following the recommended domain configuration in the getting started guide.
5. steveiliop56

   closed this as completedon Jul 15, 2026
6. cirogargatagli commented on Jul 21, 2026

   

   cirogargatagli

   on Jul 21, 2026

   Author

   More actions

   Thanks for the clarification.

   I understand the security concern and the current behavior makes sense for public domains.

   Would it be possible to add an explicit configuration override for advanced/private DNS setups?

   For example:

   TINYAUTH_COOKIE_DOMAIN=".home"

   or:

   TINYAUTH_COOKIE_DOMAIN="home"

   The default behavior could remain unchanged, but users running private DNS zones (homelabs, internal domains, split DNS, etc.) could manually define the cookie scope.

   The administrator would be responsible for ensuring that the domain is controlled and trusted.

   This would allow setups like:

   tinyauth.home
   jellyfin.home
   immich.home

   to share the same authentication session without requiring an additional artificial parent domain.

   Something similar to how many reverse proxies allow explicit cookie domain configuration would be very useful.

   Thanks!
7. steveiliop56 commented on Jul 21, 2026

   

   steveiliop56

   on Jul 21, 2026

   Member

   More actions

   Unfortunately this is not possible. The public suffix list is not only used by Tinyauth but by browsers as well. This means that even if I allowed Tinyauth to set cookies for .home, browsers would immediately ignore it. I suggest either buying a domain name or just using something like app.lab.home.