lukas.pupkalipinski/BanGUI
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: mark blocklist fail2ban path bug as fixed

Browse Source
This commit is contained in:
Lukas
2026-03-01 20:49:21 +01:00
parent 19bb94ee47
commit d1d6366cd2
1 changed files with 11 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
Docs/Tasks.md
View File

@@ -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_