Base domain names must match on private tld

[b-reich]

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:

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

[notquitenothing]

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

[b-reich]

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

[notquitenothing]

Planning on a release in the next few days 😊 🎄

[notquitenothing]

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

[b-reich]

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.

[notquitenothing]

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.

[b-reich]

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

[notquitenothing]

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]

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

.lan should be cover by the rfc.

[notquitenothing]

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.