Refactor fail2ban client to use vendored adapter

This commit is contained in:
2026-04-12 19:25:56 +02:00
parent 21b38365c4
commit e271207795
3 changed files with 162 additions and 148 deletions

View File

@@ -93,6 +93,7 @@ Reference: `Docs/Refactoring.md` for full analysis of each issue.
- Issue: `app.utils.fail2ban_client` reimplements low-level socket framing, command encoding, and protocol parsing rather than using the vendored fail2ban client classes, creating duplicated protocol logic and an unclear source of truth.
- Propose: Introduce a fail2ban adapter interface and either wrap the vendored `fail2ban-client` implementation or refactor the custom client so it is the single canonical integration point. Ensure all services depend on the adapter abstraction rather than raw socket details.
- Test: Add adapter-level unit tests and service tests that can swap in a fake fail2ban adapter, proving the backend no longer couples business logic directly to low-level socket protocol code.
- Status: completed
13. Introduce explicit schema migration/versioning for the runtime database
- Goal: Allow BanGUI to evolve its application database schema safely across releases and prevent startup failures caused by schema drift.