From d1d6366cd2594e04db7deafd14ffa51ab9bc0daf Mon Sep 17 00:00:00 2001 From: Lukas Date: Sun, 1 Mar 2026 20:49:21 +0100 Subject: [PATCH] docs: mark blocklist fail2ban path bug as fixed --- Docs/Tasks.md | 64 +++++++++------------------------------------------ 1 file changed, 11 insertions(+), 53 deletions(-) diff --git a/Docs/Tasks.md b/Docs/Tasks.md index 2181c10..b0a8110 100644 --- a/Docs/Tasks.md +++ b/Docs/Tasks.md @@ -4,59 +4,17 @@ This document breaks the entire BanGUI project into development stages, ordered --- -## ✅ DONE — Issue: Vite proxy ECONNREFUSED +## ✅ FIXED — Blocklist import: `No module named 'fail2ban'` on every IP (2026-03-01) -**Problem:** The Vite dev server (running inside the frontend container) proxied -`/api` to `http://localhost:8000`. Inside the container network `localhost` -resolves to the container itself, not the backend service, causing -`AggregateError [ECONNREFUSED]` for every API call. +**Root cause:** In `app/main.py`, the `fail2ban-master` path was computed using +`Path(__file__).resolve().parents[2] / "fail2ban-master"`. This resolves correctly +in local dev (`backend/app/main.py` → repo root) but resolves to `/fail2ban-master` +inside the Docker container (where the source is copied to `/app/app/main.py`), +so `fail2ban` was never added to `sys.path` and `pickle.loads()` raised +`ModuleNotFoundError: No module named 'fail2ban'` for every socket response. -**Fix:** Changed `vite.config.ts` proxy target from `http://localhost:8000` to -`http://backend:8000` so Vite uses the Docker/Podman compose service DNS name -to reach the backend container over the shared network. +**Fix:** Replaced the hardcoded `parents[2]` with a walk-up loop +(`_find_fail2ban_master()`) that iterates over all ancestors until it finds a +`fail2ban-master/` sibling directory — correct in both local dev and Docker. ---- - -**Problem:** No DB present did not forward to setup page; setup page was not redirecting to login when already done. - -**Fix:** -- Added `SetupGuard` component (`src/components/SetupGuard.tsx`) that calls `GET /api/setup` on mount and redirects to `/setup` if not complete. -- All routes except `/setup` are now wrapped in `SetupGuard` in `App.tsx`. -- `SetupPage` calls `GET /api/setup` on mount and redirects to `/login` if already complete. - ---- - -## ✅ DONE — Issue: Setup - Error during setup (500) - -**Problem:** `POST /api/setup` returned 500 on some runs. - -**Root cause:** `bcrypt.hashpw` and `bcrypt.checkpw` are CPU-bound blocking calls. Running them directly in an async FastAPI handler stalls the event loop under concurrent load, causing timeouts / 500 responses. - -**Fix:** -- `setup_service.run_setup` now offloads bcrypt hashing to `loop.run_in_executor(None, ...)`. -- `auth_service._check_password` was converted from a sync to an async function, also using `run_in_executor`. - ---- - -## ✅ DONE — Issue: Setup - Security issue (password in plaintext) - -**Problem:** `master_password` was transmitted as plain text in the `POST /api/setup` and `POST /api/auth/login` request bodies. - -**Fix:** -- Added `src/utils/crypto.ts` with a `sha256Hex(input)` helper using the browser-native `SubtleCrypto` API. -- `SetupPage.handleSubmit` now SHA-256 hashes the password before submission. -- `api/auth.ts login()` now SHA-256 hashes the password before the login POST. -- The backend stores `bcrypt(sha256(password))`. The plaintext never leaves the browser. - ---- - -## ✅ DONE — Clean command - -**Problem:** No easy way to wipe all debug compose volumes and start fresh. - -**Fix:** Added `Makefile` at the project root with targets: -- `make up` — start the debug stack (detached) -- `make down` — stop the debug stack -- `make restart` — restart the debug stack -- `make logs` — tail all logs -- `make clean` — `compose down -v --remove-orphans` (removes all debug volumes) +**Commit:** `19bb94e` — _Fix fail2ban-master path resolution for Docker container_ \ No newline at end of file