Serving pihole v6 behind a custom subpath seems to be broken again

[fozid]

The issue I am facing: Getting pihole running behind a custom subpath

Details about my system: debian 12 bare metal install

What I have changed since installing Pi-hole: nothing

Details

I followed the info at the bottom of this link → Setup lighttpd reverse proxy for v6 and got it all serving behind pihole2 so i visit 192.168.1.4:8080:/pihole2/admin to view the web ui.

This broke recently although i dont know when as i only visit the ui when i need to, which isnt often. I removed the subpath from the .toml file, restarted the app, and could access the ui though /admin, so reimplemented the subpath and it fails. some parts of the app get served behind the custom subpath, other parts dont.

[rdwebdesign]

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

[fozid]

@rdwebdesign

pihole -d

https://tricorder.pi-hole.net/prfVlAN4/

[rdwebdesign]

Your debug log shows you are running nginx.
Please share your reverse proxy configuration.

[fozid]

I do run it behind nginx when accessing remotely, but currently before looking at the reverse proxy, my issue is accessing the specified endpoint locally. I can access 192.168.1.4:8080/admin when no subpath is set, but it fails with /pihole set when visiting 192.168.1.4:8080/pihole/admin as seen in my logs

[rdwebdesign]

Please share your reverse proxy configuration.

[fozid]

Location /pihole/ { proxy_pass http://192.168.1.4:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }

[fozid]

you can close his issue if you want. since v6 i have had nothing but trouble with serving multiple instances of pihole. it works for a bit then breaks. obviously it is not intended for use how i am using it, so i have moved to adguard home instead.

[dan.danache]

I have the same problem, using Caddy as SSL terminator.

# Caddyfile
my.domain {
    handle_path /sinkhole/* {
        reverse_proxy localhost:9080
    }
}

# pihole.toml (v6.2.3)
[webserver]
domain = "my.domain"
port = "9080"

[webserver.paths]
prefix = "/sinkhole"

If I go to https://my.domain/sinkhole/

1. I am redirected (as expected) to https://my.domain/sinkhole/admin/login

2. The front-end makes a GET /sinkhole/api/auth REST request that fails with 401 Unauthorized (expected)

3. I enter the password and click “Log-in (uses cookie)“

4. The front-end makes a POST /sinkhole/api/auth REST request containing the password and gets back 200 OK

5. The session cookie is successfully set: Set-Cookie: sid=FT0DlFzoc7ZZHFPKkxp3Jw=; SameSite=Lax; Path=/; Max-Age=1800; HttpOnly

6. Front-end sends me to /sinkhole/admin/ and the HTML page loads all right, with all CSS/JS/IMG resources.

7. Problem!: CSRF HTML header is empty although the Cookie: sid=FT0DlFzoc7ZZHFPKkxp3Jw= header is sent in along the GET /sinkhole/admin/ request:

   <meta name="csrf-token" content="">
   

8. Front-end makes a GET /sinkhole/api/stats/summary REST request that contains the Cookie: sid=FT0DlFzoc7ZZHFPKkxp3Jw= and x-csrf-token: headers (empty CSRF Token)

9. Back-end responds with 401 Unauthorized

10. I see this in FTL.log:

    DEBUG_API: Read sid="FT0DlFzoc7ZZHFPKkxp3Jw=" from cookie
    DEBUG_API: API Authentication: FAIL (CSRF token mismatch, received "", expected "MHZuxjrpSciAkCnuIkwdog=")
    WARNING: API: Unauthorized (key: unauthorized)
    

11. Page enters a redirect loop:
    i. After the REST API call fails with 401, the front-end refreshes the page, probably thinking the session expired and hoping to redirect to /sinkhole/admin/login. But that does not happen since the browser sends the sid cookie. Even if I manually go to /sinkhole/admin/login, I get redirected back to /sinkhole/admin/, since that page sees me as logged in.
    ii. When the HTML page loads again, the header meta csrf-token is still empty, so all API REST calls fail, then the page reloads again.

---

Everything works fine with this config:

# Caddyfile
my.domain {
    reverse_proxy /admin/* localhost:9080
    reverse_proxy /api/* localhost:9080
}

# pihole.toml (v6.2.3)
[webserver]
domain = "my.domain"
port = "9080"

[webserver.paths]
prefix = ""

And I access the Pi-hole front-end without the /sinkhole prefix. But I really dislike this workaround and would like to use the custom subpath setup.

I tried to look around in the source code FTL::auth.c, web::header.lp but stuff there is way above my pay grade

Thank you for your help!