Details about my system:
Docker Setup of development-v6 deployed on September 26th
version: "3"
# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
pihole:
container_name: pihole
image: pihole/pihole:development-v6
# For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
ports:
- "53:53/tcp"
- "53:53/udp"
- "80:80/tcp"
- "443:443/tcp"
environment:
TZ: 'Europe/Amsterdam'
# WEBPASSWORD: 'set a secure password here or it will be random'
# Volumes store your data between container upgrades
volumes:
- './etc-pihole:/etc/pihole'
- './etc-dnsmasq.d:/etc/dnsmasq.d'
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
restart: unless-stopped
What I have changed since installing Pi-hole:
Used "pihole setpassword"
Thanks for investigating.
There might be an issue with the API, but you should not set a password within the container with pihole setpassword but use the environment variable FTLCONF_webserver_api_password to set the password.
The GET for /api/auth/sessions requires a valid session. From your screenshots, it looks like your not sending your SID with the request and Pi-hole will reply with 401 as expected.
I also tried to send the SID in the header using "Authorization"="SID", and "Authorization"="sid="SID"", etc.
I also redeployed using the " FTLCONF_webserver_api_password" environment variable and I get the same result, /api/auth works, but anything else that has a 401 schema(https://ftl.pi-hole.net/new/http/docs/#get-/info/ftl) fails.
When the cookie is used to send the SID, you'll also need to send the CSRF token provided by the API during login. This is to prevent possible Cross-Site-Request-Forgery attacks and commonly found with web APIs. If you'd rely on authentication via cookie only, third-party pages could send requests to your Pi-hole (and the browser would automatically attach the cookie to this request) when you happen to be logged in in the same browser (which is quite likely). Hence, a second secret (the CSRF token) needs to be added that is not available to third party sites.
If you open the Pi-hole web interface and use the Developer tools, you will see that this is precisely what the Pi-hole web interface does when communication with the API.
When you go to index - powered by h5ai v0.30.0 (https://larsjung.de/h5ai/) and hover over the available authentication methods for endpoint on the top right of each individual endpoint, you will notice that using the Authorization header isn't the right choice (following its documentation, the Authorization header is used only for Basic and Digest authentication, both aren't used by Pi-hole).
You can either use
sid in any JSON payload you are sending to the API (if the endpoint accepts a payload), or
sid provided by a cookie + CSRF token in header X-CSRF-TOKEN (see Pi-hole web interface), or
sid in the header, or
X-FTL-SID in the header
We will shortly be working on documenting this more explicitly. I am sorry we haven't done this before but we probably have, for once, forgotten about it with all the changes we did to the new API and, secondly, we also didn't expect early-adopters before the official announcement of v6.0 beta.
Thank you for your time and patience. It works now. I saw that the /api/auth POST returns a CSRF Token, but I didn't look into the request headers thoroughly enough and thought it's not being used yet.
[quote="DL6ER, post:9, topic:65221]
I am sorry we haven't done this before but we probably have, for once, forgotten about it with all the changes we did to the new API
[/quote]
You don't have to apologise, I understand this is pre-release, and I want to thank you for your quick and insightful response.
