Raspberry Pi 3 Model B Rev 1.2 running buster.
Pihole Core version is v6.2.2 , Web version is v6.3, FTL version is v6.3.3.
DCHP serving and DNS blocking.
What I have changed since installing Pi-hole: Upgrade to v6
Problem
I am running a perl script on my ubuntu laptop which is issuing curls to pihole and parsing the output.
I can POST an /api/auth to get the sid, GET /api/dhcp/leases then DELETE the session. That’s successful, but I am having problems with enabling or disabling ads with POST /api/dns/blocking. These are the curls and their responses.
#get the session sid
curl -s -k -X POST --data '{"password":"Mf1uuL9NFOXG9HNsOHIVtQhx2wLwNtZVprLfVsrZ2D8="}' http://pihole.local:8080/api/auth #Response:
{"session":{"valid":true,"totp":false,"sid":"yna1LcWgotqLQ+jM+2fVTg=","csrf":"VE1aCkioMlL+OuIs1bs9Kw=","validity":1800,"message":"app-password correct"},"took":2.1178107261657715}
#then try to block ads:
curl -s -k -X POST --data '{"sid":"yna1LcWgotqLQ+jM+2fVTg=","blocking":"true"}' http://pihole.local:8080/api/dns/blocking #Response
{"error":{"key":"body_error","message":"No "blocking" boolean in body data","hint":null},"took":0.0002460479736328125} #same response with blocking false.
The error already hints at it but you have to supply a boolean (true or false) and not a string like "true" in your example.
Try below instead:
curl -s -k -X POST --data '{"sid":"yna1LcWgotqLQ+jM+2fVTg=","blocking":true}' http://pihole.local:8080/api/dns/blocking
Ps. I dont recommend using above .local as a search/suffix domain.
Thats a special domain intended for mDNS and not for regular old school DNS.
From the mDNS RFC:
Appendix G. Private DNS Namespaces
The special treatment of names ending in ".local." has been
implemented in Macintosh computers since the days of Mac OS 9, and
continues today in Mac OS X and iOS. There are also implementations
for Microsoft Windows [B4W], Linux, and other platforms.
Some network operators setting up private internal networks
("intranets") have used unregistered top-level domains, and some may
have used the ".local" top-level domain. Using ".local" as a private
top-level domain conflicts with Multicast DNS and may cause problems
for users. Clients can be configured to send both Multicast and
Unicast DNS queries in parallel for these names, and this does allow
names to be looked up both ways, but this results in additional
network traffic and additional delays in name resolution, as well as
potentially creating user confusion when it is not clear whether any
given result was received via link-local multicast from a peer on the
same link, or from the configured unicast name server. Because of
this, we recommend against using ".local" as a private Unicast DNS
top-level domain. We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:
Ps2. above -k argument only applies for https and not for http:
$ man curl
[..]
-k, --insecure
(TLS SFTP SCP) By default, every secure connection curl
makes is verified to be secure before the transfer takes
place. This option makes curl skip the verification step and
proceed without checking.
Yes - noted that thanks.
I’ll mention here a point in case others read it.
My reading of the documentation suggested that sid’s had to be uri encoded before use. For me just using the value extracted from /api/auth worked but encoding broke it.