Question about Lighttpd config "Access-Control-Allow-Origin"

[MichaIng]

Hey guys, just a little question about the following part of the official Pi-hole Lighttpd config:

pi-hole/advanced/lighttpd.conf.debian

Lines 72 to 75 in 5c17e41

	$HTTP["url"] =~ ".ttf$" {
	# Allow Block Page access to local fonts
	setenv.add-response-header = ( "Access-Control-Allow-Origin" => "*" )
	}

I got a little confused since it says "Block Page" while it's in the $HTTP["url"] =~ "^/admin/", hence only valid when accessing the admin page. I was reading and thinking through it, but not sure if I got it right: Is it to allow requests accessing the local fonts inside the /admin/ dir even that the originating request was either to the blocking page or to an ad host? E.g. one accesses a blocked domain, which then is redirected to the blocking page (if enabled) and the blocking page uses fonts files within the admin page directory, which is usually blocked when the requested host (blocked domain) does not match the Pi-hole host... or similar?

Nothing urgent but the question just came up when I updated our (DietPi) webserver configs according to recently added new fonts file types: https://github.com/pi-hole/pi-hole/pull/3403/files#r432926507

[PeterDaveHello]

I got a little confused since it says "Block Page" while it's in the $HTTP["url"] =~ "^/admin/", hence only valid when accessing the admin page.

Actually it means every url starts with /admin/, as you can see in the comment here(a few line upper):

pi-hole/advanced/lighttpd.conf.debian

Line 91 in cbfb58f

# If the URL starts with /admin, it is the Web interface

So as you can see the response header responded with Access-Control-Allow-Origin header:

$ curl -I http://127.0.0.1/admin/style/vendor/bootstrap/fonts/glyphicons-halflings-regular.ttf
HTTP/1.1 200 OK
Content-Type: font/ttf
Accept-Ranges: bytes
ETag: "862467064"
Last-Modified: Wed, 27 Jan 2021 18:38:49 GMT
Expires: Fri, 12 Feb 2021 08:58:04 GMT
Cache-Control: max-age=0
Access-Control-Allow-Origin: *
Content-Length: 45404
Date: Fri, 12 Feb 2021 08:58:04 GMT
Server: lighttpd/1.4.53

but not sure if I got it right: Is it to allow requests accessing the local fonts inside the /admin/ dir even that the originating request was either to the blocking page or to an ad host?

Yes, using app-measurement.com which is default blocked by built-in adblock rule sets as an example:

You can see it's using fonts under the /admin/ path (http://app-measurement.com/admin/style/vendor/SourceSansPro/source-sans-pro-v13-latin-regular.woff2, please note that the latest Access-Control-Allow-Origin header setting is applied to other fonts format like woff2, not only ttf, see d90313f for more details), it's triggered by blockingpage.css:

pi-hole/advanced/index.php

Line 75 in cbfb58f

<link rel='stylesheet' href='pihole/blockingpage.css'>

pi-hole/advanced/blockingpage.css

Lines 120 to 128 in cbfb58f

	@font-face {
	font-family: "Source Sans Pro";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: local("Source Sans Pro Regular"), local("SourceSansPro-Regular"),
	url("/admin/style/vendor/SourceSansPro/source-sans-pro-v13-latin-regular.woff2") format("woff2"),
	url("/admin/style/vendor/SourceSansPro/source-sans-pro-v13-latin-regular.woff") format("woff");
	}

E.g. one accesses a blocked domain, which then is redirected to the blocking page (if enabled) and the blocking page uses fonts files within the admin page directory, which is usually blocked when the requested host (blocked domain) does not match the Pi-hole host... or similar?

I don't think it's a http redirect, it's the same domain, but point the host to Pi-hole's address, by Pi-hole as DNS, so that Pi-hole will respond to the request, and in this case, the http service won't use virtual host to bind to a certain hostname but respond to all requests no matter what hostname it is, there isn't host matching issue, unless the client is using https protocol, which will have host matching issue on the https cert.

Hope this help you clarify the question.

[MichaIng]

Many thanks for the detailed answer. Indeed some development tools testing clarifies much 👍

So the fonts are accessed as local request, and indeed it's not a HTTP redirect but internal rewrite due to server.error-handler-404 = "/pihole/index.php".

CORS is not allowed by default for the admin panel (https://github.com/pi-hole/AdminLTE/blob/master/scripts/pi-hole/php/auth.php) but that would only cause issues if admins manually applied a server.name to Lighttpd, the script is not processed here and it wouldn't check or respect previously set headers anyway but die directly.

So then I'm wondering for the purpose of that response header, since nothing would prevent access to those fonts anyway. But I should simply test it.

[yubiuser]

@MichaIng

Does the issue still persist? Did you ever test it?

[MichaIng]

Just did a test, and removing the header does not prevent the browser from loading the fonts, when enabling the blocking page and accessing a blocked domain. Even when setting the header value to an explicit domain, which does not match the blocked domain, the browser (MS Chromium Edge) loads and uses the fonts, no error, no warning. This makes sense as the URL to the resource is an internal one, so the resource is from client point of view served from the blocked domain, the header has no purpose.

Now I changed the URLs for the fonts to absolute ones, using the local IP of the Pi-hole test instance, and voila:

Access to font at 'http://192.168.1.22/admin/style/vendor/SourceSansPro/source-sans-pro-v13-latin-regular.woff2' from origin 'http://google.com' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains the invalid value 'dietpi.com'.

So the header has no relevance as all resource URLs are internal ones, no absolute ones, reasonably.

[MichaIng]

Fixed with #4275