Base domain names must match on private tld

b-reich commented

2025-12-20 12:26:17 -06:00

(Migrated from github.com)

Describe the bug:

Hey, I am running a private zone for the TLD “.lan”.
This is not supported when I use the proxy auth feature.

{
  "message": "ProxyAuth Domain base domain sonarr.lan does not equal $APP_URL base domain auth.lan. Base domain names must match."
}

To Reproduce:

setup DNS zone with ".lan"
create entries for auth.lan and myapp.lan
setup reverseproxy with proxy auth
visit myapp.lan

Expected behavior:

serve myapp.lan after login

### Describe the bug: Hey, I am running a private zone for the TLD “.lan”. This is not supported when I use the proxy auth feature. ```json { "message": "ProxyAuth Domain base domain sonarr.lan does not equal $APP_URL base domain auth.lan. Base domain names must match." } ``` ### To Reproduce: 1. setup DNS zone with ".lan" 2. create entries for auth.lan and myapp.lan 3. setup reverseproxy with proxy auth 4. visit myapp.lan ### Expected behavior: serve myapp.lan after login

❤️ 1

notquitenothing commented

2025-12-20 14:58:10 -06:00

(Migrated from github.com)

Thank you for opening an issue! I think I can make a patch for this 😊

❤️ 1 🚀 1

b-reich commented

2025-12-22 02:49:30 -06:00

(Migrated from github.com)

@notquitenothing thanks for the quick fix. Any plans to create an new release in the next days? Wishing you a wonderful holiday season!

notquitenothing commented

2025-12-22 12:18:38 -06:00

(Migrated from github.com)

Planning on a release in the next few days 😊 🎄

❤️ 1

notquitenothing commented

2025-12-23 10:21:19 -06:00

(Migrated from github.com)

This should be fixed in the latest release v1.7.0, let me know if it works/does not work for you

This should be fixed in the latest release [v1.7.0](https://github.com/voidauth/voidauth/releases/tag/v1.7.0), let me know if it works/does not work for you

❤️ 1

b-reich commented

2025-12-24 02:49:11 -06:00

(Migrated from github.com)

Not quietd sure if I mess something up. But I am trap in a redirect loop.
This may relate to changes in 1.7.0 in general 1.6.0 seems to work for me.

Not quietd sure if I mess something up. But I am trap in a redirect loop. This may relate to changes in 1.7.0 in general 1.6.0 seems to work for me.

😕 1

notquitenothing commented

2025-12-24 09:58:25 -06:00

(Migrated from github.com)

Well bummer! Releasing a patch now (v1.7.1) to revert that change until more test cases can be put together. ProxyAuth Domains will continue to not work with custom private DNS zones until a fix can be found, but it should fix the login redirect loop. Please let me know if updating to this version fixes the redirect loop for you.

Root cause of this issue is that browsers will not let you set cookies on top level domains (.com, .org, .co.uk), but will maybe(?) let you set them on top level custom domains (.lan) but it is not clear how to detect those cases reliably.

Well bummer! Releasing a patch now ([v1.7.1](https://github.com/voidauth/voidauth/releases/tag/v1.7.1)) to revert that change until more test cases can be put together. ProxyAuth Domains will continue to not work with custom private DNS zones until a fix can be found, but it should fix the login redirect loop. Please let me know if updating to this version fixes the redirect loop for you. Root cause of this issue is that browsers will not let you set cookies on top level domains (`.com`, `.org`, `.co.uk`), but will maybe(?) let you set them on top level custom domains (`.lan`) but it is not clear how to detect those cases reliably.

b-reich commented

2025-12-25 03:47:36 -06:00

(Migrated from github.com)

The redirect loop is fixed.
Do you have to set cookies on the tld? Are cookies for "auth.lan" not enough?

The redirect loop is fixed. Do you have to set cookies on the tld? Are cookies for "auth.lan" not enough?

👍 1

notquitenothing commented

2025-12-25 12:03:05 -06:00

(Migrated from github.com)

For ProxyAuth to work the VoidAuth session cookie needs to be set on a base (root) domain that covers both VoidAuth itself and the domain to be protected. Then, when accessing the protected domain the VoidAuth session cookie is sent as well, which the reverse proxy will use to determine if access should be granted.
This can get complicated, browsers only let you set cookies on domains you would own if you owned the setting-domain. (From auth.example.com you can set example.com but not com. And if you try to set a cookie on a domain that isn’t allowed, there is no error the cookie is just not set. I am going to add an optional environment variable to override the session domain to allow experimentation on what works without breaking the default setup.

This is related to (closed) #177 I believe.

For ProxyAuth to work the VoidAuth session cookie needs to be set on a base (root) domain that covers both VoidAuth itself and the domain to be protected. Then, when accessing the protected domain the VoidAuth session cookie is sent as well, which the reverse proxy will use to determine if access should be granted. This can get complicated, browsers only let you set cookies on domains you would own if you owned the setting-domain. (From `auth.example.com` you can set `example.com` but not `com`. And if you try to set a cookie on a domain that isn’t allowed, there is no error the cookie is just not set. I am going to add an optional environment variable to override the session domain to allow experimentation on what works without breaking the default setup. This is related to (closed) #177 I believe.

b-reich commented

2025-12-25 13:48:12 -06:00

(Migrated from github.com)

https://www.rfc-editor.org/rfc/rfc6762#appendix-G

.lan should be cover by the rfc.

https://www.rfc-editor.org/rfc/rfc6762#appendix-G .lan should be cover by the rfc.

notquitenothing commented

2025-12-25 15:12:07 -06:00

(Migrated from github.com)

Ya, after reading appx. G of that RFC I agree, the initial change (that caused the redirect loop) seems like it should have worked. There must be some other spec that browser makers are following to disallow setting cookies at lan. Once #217 is merged you should be able to override the session cookie domain yourself and see what works.

Ya, after reading appx. G of that RFC I agree, the initial change (that caused the redirect loop) seems like it should have worked. There must be some other spec that browser makers are following to disallow setting cookies at `lan`. Once #217 is merged you should be able to override the session cookie domain yourself and see what works.

notquitenothing commented

2025-12-25 19:21:25 -06:00

(Migrated from github.com)

The SESSION_DOMAIN environment variable should be available in v1.7.2, to attempt to get proxyAuth working between auth.lan and sonarr.lan you can set it like SESSION_DOMAIN: 'lan'. I would also recommend clearing your cookies on auth.lan beforehand. If this does not work and you get a redirect loop or just sent back to the login page after completing a login, you have a couple of options:

Go without ProxyAuth Domains when using VoidAuth
Change your private DNS zone to something that can (probably) be set, ex. auth.example.lan and sonarr.example.lan

This might be a technical limitation that VoidAuth cannot overcome due to browser cookie/tracking policies, let me know how it goes.

Also let me know if you have used a different Identity Provider that does overcome this issue, and I will research how they are doing it 😊

The SESSION_DOMAIN environment variable should be available in [v1.7.2](https://github.com/voidauth/voidauth/releases/tag/v1.7.2), to attempt to get proxyAuth working between `auth.lan` and `sonarr.lan` you can set it like `SESSION_DOMAIN: 'lan'`. I would also recommend clearing your cookies on `auth.lan` beforehand. If this does not work and you get a redirect loop or just sent back to the login page after completing a login, you have a couple of options: * Go without ProxyAuth Domains when using VoidAuth * Change your private DNS zone to something that can (probably) be set, ex. `auth.example.lan` and `sonarr.example.lan` This might be a technical limitation that VoidAuth cannot overcome due to browser cookie/tracking policies, let me know how it goes. Also let me know if you have used a different Identity Provider that **does** overcome this issue, and I will research how they are doing it 😊

b-reich commented

2026-01-01 09:22:12 -06:00

(Migrated from github.com)

mhmm using .lan still resulting in redirect loop
just change to a proper tld "examlple.dev", now with proper lets encrypt instead driving an own CA.

Thanks @notquitenothing !

mhmm using .lan still resulting in redirect loop just change to a proper tld "examlple.dev", now with proper lets encrypt instead driving an own CA. Thanks @notquitenothing !

❤️ 1

notquitenothing commented

2026-01-02 19:27:11 -06:00

(Migrated from github.com)

Assumed resolved (as much as it can be) in v1.8.0 . Please re-open if it is not

Rows
Columns

Base domain names must match on private tld #210

Describe the bug:

To Reproduce:

Expected behavior: