Cannot disable pihole using the web interface

Hello,

at first the options to diable pihole using the webinterface wern’t working using my iPad, but using Chrome on Windows worked fine. Now all those options won’t work, even when using Microsoft Edge. A loading icon appears but nothing happens.

I have no JS-blocker or ad-blocker running…

Is there a fix for this?

Please send us the token generated by

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

My debug token is: https://tricorder.pi-hole.net/l0i9rdfv3t

From your debug log. Log out of the admin GUI and log in with the correct password:

-rw-r--r-- 1 www-data www-data 484 Mar 24 18:09 /var/log/lighttpd/error.log
   2020-03-24 17:26:09: (server.c.1464) server started (lighttpd/1.4.53) 
   2020-03-24 17:26:15: Wrong token! Please re-login on the Pi-hole dashboard.
   2020-03-24 17:29:38: Wrong token! Please re-login on the Pi-hole dashboard.
   2020-03-24 18:00:08: Wrong token! Please re-login on the Pi-hole dashboard.

I logged out and in again, but the result is still the same…

You currently have blocking disabled. From the web interface, can you enable it?

What changes have you made to lighttpd? Yours is not the one we ship with.

Yours:

*** [ DIAGNOSING ]: contents of /etc/lighttpd

-rw-r--r-- 1 root root 2053 Dec 19 20:49 /etc/lighttpd/lighttpd.conf
   server.modules = (
   	"mod_indexfile",
   	"mod_setenv",
   	"mod_access",
   	"mod_alias",
    	"mod_redirect",
   )
   server.document-root        = "/var/www"
   server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
   server.errorlog             = "/var/log/lighttpd/error.log"
   server.pid-file             = "/var/run/lighttpd.pid"
   server.username             = "www-data"
   server.groupname            = "www-data"
   server.port                 = 80
   server.http-parseopts = (
     "header-strict"           => "enable",
     "host-strict"             => "enable",
     "host-normalize"          => "enable",
     "url-normalize-unreserved"=> "enable",
     "url-normalize-required"  => "enable",
     "url-ctrls-reject"        => "enable",
     "url-path-2f-decode"      => "enable",
    
     "url-path-dotseg-remove"  => "enable",
    
    
   )
   index-file.names            = ( "index.php", "index.html" )
   url.access-deny             = ( "~", ".inc" )
   static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
   compress.cache-dir          = "/var/cache/lighttpd/compress/"
   compress.filetype           = ( "application/javascript", "text/css", "text/html", "text/plain" )
   include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
   include_shell "/usr/share/lighttpd/create-mime.conf.pl"
   include "/etc/lighttpd/conf-enabled/*.conf"
   server.modules += (
   	"mod_compress",
   	"mod_dirlisting",
   	"mod_staticfile",
   )

Ours:
https://raw.githubusercontent.com/pi-hole/pi-hole/master/advanced/lighttpd.conf.debian

I haven’t done any changes to the lighttpd.conf - but I am running dietpi on a rpi4. Pihole is already available within dietpi, so I guess the config was changed by the devs of dietpi…

@MichaIng

@ProXy
Some guess, could you try:

sed -i '/"url-normalize-required"/s/"enable"/"disable"/g' /etc/lighttpd/lighttpd.conf
systemctl restart lighttpd

I guess it is the same problem with new Lighttpd settings that drive us crazy at Nextcloud: https://github.com/nextcloud/server/issues/17065#issuecomment-573243754
No idea what drives the dev to do something like this, which is highly unexpected and clearly breaks any PHP application that transfers session tokens via GET request. And even worse to enable those by default: https://www.lighttpd.net/2019/5/27/1.4.54/

With v6.29, DietPi will disable all those kind of pre-decoding/“normalisation” settings, as this it’s simply not the job of the webserver to alter the query string for any reason: https://github.com/MichaIng/DietPi/blob/18f76da026194ad91724f8a1e7b80bf0f5197467/dietpi/dietpi-software#L6995-L7009

So it seems the problem is with DietPi and not with Pi-hole.

I can confirm that disabling “url-normalize-required” in lighttpd.conf solves the problem of not being able to disable pihole using the web interface. I also ran into this with pihole Beta 5.0 on DietPi/Rpi3.

1 Like

It has nothing to do with DietPi, as linked, these are new settings of Lighttpd, enabled by default, as well on all major distros with Lighttpd v1.4.54+. If I understood it correctly, some of them even need to be set disabled (instead of not adding them to lighttpd.conf), hence this might become relevant for the Pi-hole lighttpd.conf as well.

But indeed the one setting that causes this GET request query string issues can be simply removed/commented, and as it is not present in Pi-hole lighttpd.conf, this is currently only on issue when the web server install is skipped via installer, i.e. DietPi in current version. For next release (will become beta the next days) we set all those settings to disabled actively.

I already thought to collect all cases where those cause issues to convince the Lighttpd dev to disable them by default. In every case where users e.g. upgrade Lighttpd and choose to use the maintainer config file version, things will be broken otherwise…


And little note about why it work sometimes, but not in most cases (when the setting is enabled):

  • Lighttpd with this setting decodes the query string (things like “2%B” that is encoded “+” symbol).
  • If the token/query string now contains a “+”, this is send encoded as “2%B” in the query string.
  • Lighttpd with this setting now decodes it, so it becomes a “+” again. PHP then decodes it a second time before storing the content in the _GET array. And since the “+” again codes for a white space, the string will have a white space where a “+” was wanted.
  • This 2%B => “+” => white space is currently the only relevant case where double decoding causes issues, but there might be others.
  • Hence if the session token by chance does not contain a “+”, the doubled decoding does not cause an issue and everything will function. But for statistical reasons in most cases the session token contains a “+”, hence things are broken by doubled decoding.