main() read the setting 'PIHOLEAPI_SSL_VERIFY', but config.json defines
the function VERIFY_SSL, so the real key is PIHOLEAPI_VERIFY_SSL.
get_setting_value() returns "" for a key nobody defined, so every Pi-hole
API request got verify="": certificate checks were always off and the
InsecureRequestWarning was suppressed, even when a user had turned on
"Verify SSL". The login request sends the Pi-hole web password to
api/auth. The plugin README and docs/PIHOLE_GUIDE.md used the wrong name
too. test_plugin_conventions.py did not catch it: it only looks at
get_setting_value("X") or <literal>, and this line had no fallback.
Changes:
- test/plugins/test_plugin_conventions.py: new
test_own_setting_keys_exist_in_config. Every literal
get_setting_value('<PREFIX>_X') in a plugin's scripts must name a
setting its own config.json defines; core settings and other plugins'
keys are not checked. Before the fix it fails for exactly one of the 54
plugins: pihole_api_scan.py, get_setting_value('PIHOLEAPI_SSL_VERIFY').
- New test/plugins/test_pihole_api_scan_verify_ssl.py: runs main() with
VERIFY_SSL true and false and checks the verify= value that reaches
requests.post() for api/auth. Only the HTTP call is mocked. It fails
before the fix (verify=None).
- server/plugins/pihole_api_scan/pihole_api_scan.py: main() reads
PIHOLEAPI_VERIFY_SSL.
- server/plugins/pihole_api_scan/README.md and docs/PIHOLE_GUIDE.md name
the setting PIHOLEAPI_VERIFY_SSL.
- docs/PLUGINS_DEV.md, Conventions Checklist: read a setting under the
exact key config.json defines; names the new check.
Impact:
"Verify SSL" now works. The default stays false, so default installs
behave as before. A user who turned it on while Pi-hole uses a
self-signed certificate will now see the login fail, as the setting
description says ("Disable if you are using a self-signed certificate").
Live check against Pi-hole v6.8 behind a proxy with an untrusted
certificate: with "Verify SSL" on the fixed code refused to log in, the
old code logged in and imported 33 entries.
Documentation overview
ℹ️ In the app hover over settings or fields/labels or click blue in-app ❔ (question-mark) icons to get to relevant documentation pages.
There is also an in-app Help / FAQ section that should be answering frequently asked questions.
📥 Installation
🐳 Docker (Fully supported)
- The main installation method is as a docker container - follow these instructions here.
💻 Bare-metal / On-server (Experimental/community supported 🧪)
-
Alternative bare-metal install forks:
- leiweibau's fork (maintained)
- pucherot's original code (un-maintained)
📚 Table of contents
📥 Initial Setup
- Synology Guide
- Subnets and VLANs configuration for arp-scan
- Scanning Remote Networks
- SMTP server config
- Custom Icon configuration and support
- Notifications
- Better name resolution with Reverse DNS
- Network treemap configuration
- Backups
- Plugins overview
🐛 Debugging help & tips
- Debugging tips
- Debugging UI not showing
- Invalid JSON errors debug help
- Troubleshooting Plugins
- File Permissions
- Performance tips
🔝 Popular/Suggested
⚙ System Management
🔎 Examples
♻ Misc
👩💻For Developers👨💻
- Setting up your DEV environment
- Server APP code structure
- Database structure
- API endpoints details
- Plugin development guide
- Settings system
- New Version notifications
- Frontend development tips
- Webhook secrets
Feel free to suggest or submit new docs via a PR.
👨💻 Development priorities
Priorities from highest to lowest:
- 🔼 Fixing core functionality bugs not solvable with workarounds
- 🔵 New core functionality unlocking other opportunities (e.g.: plugins)
- 🔵 Refactoring enabling faster implementation of future functionality
- 🔽 (low) UI functionality & improvements (PRs welcome 😉)
Design philosophy: Focus on core functionality and leverage existing apps and tools to make NetAlertX integrate into other workflows.
Examples:
1. Supporting apprise makes more sense than implementing multiple individual notification gateways
2. Implementing regular expression support across settings for validation makes more sense than validating one setting with a specific expression.
UI-specific requests are a low priority as the framework picked by the original developer is not very extensible (and afaik doesn't support components) and has limited mobile support. Also, I argue the value proposition is smaller than working on something else.
Feel free to submit PRs if interested. try to keep the PRs small/on-topic so they are easier to review and approve.
That being said, I'd reconsider if more people and or recurring sponsors file a request 😉.
🙏 Feature requests
Please be as detailed as possible with workarounds you considered and why a native feature is the better way. This gives me better context and will make it more likely to be implemented. Ideally, a feature request should be in the format "I want to be able to do XYZ so that ZYX. I considered these approaches XYZ".
➕ Pull requests (PRs)
If you submit a PR please:
- Check that your changes are backward compatible with existing installations and with a blank setup.
- Existing features should always be preserved.
- Keep the PR small, on-topic and don't change code that is not necessary for the PR to work
- New features code should ideally be re-usable for different purposes, not for a very narrow use case.
- New functionality should ideally be implemented via the Plugins system, if possible.
Suggested test cases:
- Blank setup with no DB or config
- Existing DB / config
- Sending a notification (e. g. Delete a device and wait for a scan to run) and testing all notification gateways, especially:
- Email, Apprise (e.g. via Telegram), webhook (e.g. via Discord), MQTT (e.g. via Home Assistant)
- Saving settings
- Test a couple of plugins
- Check the Error log for anything unusual
Some additional context:
- Permanent settings/config is stored in the
app.conffile - Currently temporary (session?) settings are stored in the
ParametersDB table as key-value pairs. This table is wiped during a container rebuild/restart and its values are re-initialized from cookies/session data from the browser.
🐛 Submitting an issue or bug
Before submitting a new issue please spend a couple of minutes on research:
- Check 🛑 Common issues
- Check 💡 Closed issues if a similar issue was solved in the past.
- When submitting an issue ❗enable debug❗
⚠ Please follow the pre-defined issue template to resolve your issue faster.
