~nickbp 3 years ago

So we currently have override and block sections in the toml config, each containing a list of strings for files and URLs. These filters are applied to all incoming requests.

We could define a separate allow section, which would also be a list of strings for files and URLs. If it was applied to all requests, this allow section logically conflicts with the override and block sections. Instead, we could have it only apply to a list of IP masks. For example, a (bad and confusing) name could be allow_hosts, where the contents of allow would only apply to these hosts, and all others would instead be subject to override and block.

---

Another angle: It might help if we added a "block" grouping to the filters, where each block can be applied to a subset of clients (or all clients if the subset isn't specified). This could look something the following (haven't checked if this is valid toml):

[lan_default]
applies_to = [
  "192.168.1.1/16"
]
block = [
  "/etc/badhosts",
  "/etc/verybadhosts"
]
override = [
  "/etc/hosts"
]

[iot]
applies_to = [
  "192.168.5.1/24"
]
allow = [
  "/etc/iotallow"
]

[all]
block = [
  "/etc/verybadhosts"
]

I think something like this would work. As implied by the example:

• allow cannot be combined with block/override
• The "most exact" match should win, e.g. 192.168.5.3 would be processed by the iot block
• Only one block is processed per host, even if there are multiple matches. For example 192.168.1.2 should be processed under lan but not all, hence why /etc/verybadhosts is listed in both blocks. This avoids things getting confusing as blocks are added - imagine if someone had 20 blocks and needed to then trace the logic to check which ones matched a given host (and then try and guess the processing order of blocks vs allows/overrides)
• It is invalid to have two blocks with equivalent applies_to settings

~nickbp added Next 3 years ago

~nickbp 2 years ago

In the scenario where there are only applies_to blocks and no unfiltered "all" block, the server should only respond to traffic from the applies_to blocks. This may be useful for running a public service that only allows access from certain IPs.

~nickbp 1 year, 8 months ago

At this point the only missing thing is support for applies_to. The config parser currently treats it as a no-op.