Chrome may loose session

[DL6ER]

I received a report I was able to reproduce but which is pretty hard to reproduce: You will also have to have a dual-stack network, i.e., your Pi-hole is reachable both via IPv4 and IPv6, for this to happen.

1. Log in to your Pi-hole using it's hostname (not via IP!), e.g., https://pi.hole/admin
2. Browse around the web interface
3. Eventually get logged out - it may also happen on the dashboard without doing anything

Taking a close look at the Network tab in the Developer Tools didn't reveal anything odd, but checking out the debug logs of FTL told us what happens here: When browsing to your Pi-hole via hostname, Chrome prefers to picks IPv6 to connect - and sessions are tied to IP addresses for extra safety in FTL.

It can now happen - completely randomly and all out of sudden, that Chrome instead decides that connecting via IPv4 is a brilliant idea. However, the session obtained during login is only valid for fda2:45fe:... and not 192.168.0.3 so the API replied with 403 Unauthorized causing the entire web interface to show you the login page.

What do we do about this?

My ideas:

1. Waive adding session protection by fixing it to an IP. This will make it possible to steal sessions from other computers on your network when you can either record network traffic and manage to somehow otherwise get the cookie and CSRF token. This is anyway impossible when HTTPS is used.
2. FTL can only know the IP address used when authenticating for sure. We could use the network table to get correlated IPv4 addresses but this is error-prone especially with sequential DHCP servers that may have handed out the address to another device meanwhile.
3. Somehow try to get IPv4 and IPv6 address via Javascript and include them in the login process. My idea would be to define new special hostnames like v4.pi.hole and v6.pi.hole which will only reply over said protocol. We can then get the client's IP address from /api/info/client ({"remote_addr":"fd29:...."}, etc.). This is a lot of effort and will still fail if a host has multiple IPv4 addresses in the same network (e.g. one over Ethernet and one over WiFi).

[rdwebdesign]

I think option 1 is the most common way to handle sessions.

[yubiuser]

I also think option 1 is the way to go, esp. you already listed the caveats of the other two options

but this is error-prone especially with sequential DHCP servers that may have handed out the address to another device meanwhile.

This is a lot of effort and will still fail if a host has multiple IPv4 addresses in the same network (e.g. one over Ethernet and one over WiFi).

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[yubiuser]

Fixed by the linked PR

[pralor-bot]

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/webui-behind-lighttpd-reverse-proxy/71239/6