adguard

Manages a filtering resolver over its web interface: querying whether a domain is currently blocked and by which list, adding allow exceptions that override filters, adding custom blocks, toggling protection and clearing the resolver cache. The authentication model deserves attention. A full administrator password must be supplied for every operation, there is no scoped or read-only credential, and the guidance to keep that password in an environment variable rather than the optional config file exists precisely because the file is a weaker place to keep it. The wrapper depends on the curl binary and a reachable server.

Use case: Whitelisting a site broken by a filter list

The AdGuard skill controls AdGuard Home, the self-hosted dns filter, over its http api. It checks whether a domain is blocked, edits allow and block rules, toggles protection, and can clear the dns cache, all from a small wrapper script. ## What it does - Checks the live status of a single domain and reports which rule blocked it. - Adds an allowlist exception that overrides blocklists, or a custom blocking rule. - Toggles protection and clears the dns cache through the same wrapper. - Reads credentials from environment variables, with an optional config file holding the instance url and admin user. ## When it is the wrong choice It is the wrong tool when there is no AdGuard Home instance to talk to, because the skill is a thin client over that server's api rather than a standalone filter. The admin password is required and travels in the environment, so on a shared machine that value is visible to anything able to read the process environment. ```bash ./adguard.sh status ./adguard.sh check example.com ./adguard.sh allow broken-site.com ./adguard.sh block adware-site.net ``` ## Notes Persist the instance url, username, and password in the shell profile so every session can reach the filter. Checking a domain before editing rules tells you whether it was already blocked and by which list, which avoids adding a redundant exception. Both a block rule and a whitelist exception are written as rules rather than one-off actions, so they persist until removed; note which one you added so cleanup later stays simple.