mirror of
https://github.com/taylanbakircioglu/haproxy-openmanager.git
synced 2026-09-24 03:16:24 +00:00
64d42663cd22cdb613baf6a99bd811cfcd15f678
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
02b1cb2bca |
feat: v1.5.0 — Site Wizard (Issue #14) + ACME Diagnostic Panel (Issue #13)
Closes #13, Closes #14. This release squashes the v1.4.0 → v1.5.0 development line. v1.4.0 shipped the ACME stability & enterprise audit (Issues #10/#11/#12). v1.5.0 builds on that foundation with two co-equal headline features plus a 22-round audit campaign hardening the prior configuration surface. License remains MIT for v1.5.0 (relicense to AGPL-3.0 lands in v1.5.2). ------------------------------------------------------------------ HEADLINE FEATURE A — ACME Diagnostic Panel (Issue #13) ------------------------------------------------------------------ A live pre-flight + post-failure diagnostic surface for every ACME order, reachable from the ACME Automation page. The panel exists to make ACME failures legible to operators who do NOT have shell access to the API host. Endpoints (`backend/routers/acme_diagnostics.py`): POST /api/letsencrypt/orders/{order_id}/diagnostics Run the full 5-check suite (DNS / port-80 / routing / account / agents) and humanize the order's `error_detail` (>=11 RFC-8555 problem types, backwards compatible with legacy plain-string failures). POST /api/letsencrypt/orders/{order_id}/diagnostics/ {check_id}/rerun Re-run a single check in place — used by the "Re-run" button on every row of the modal's pre-flight table. GET /api/letsencrypt/orders/{order_id}/events Merged event timeline combining the typed `acme_order_events` rows with correlated `user_activity_logs` entries (resource_type = 'letsencrypt_order' AND resource_id = order_id). The diagnostic modal auto-tails this timeline every 5 seconds while open. Service-level checks (`backend/services/acme_diagnostics.py`): * DNS resolution via stdlib socket.gethostbyname_ex through run_in_executor (intentionally avoiding an aiodns runtime dep for v1.5.0). * Port-80 HEAD probe, target locked to the order's domains, success on HTTP 200 OR 404, warns on egress timeout (corp egress policies routinely blackhole outbound 80 — fail-hard would be too noisy). * SSRF guard: probe refuses non-public IPs and surfaces the skip in the diagnostic result; IPv4-mapped IPv6 normalisation closes the `::ffff:169.254.169.254` cloud-metadata vector. * HAProxy routing presence check: matches the order's cluster_ids to a port-80 HTTP frontend. * ACME account validity check against `letsencrypt_accounts`. * Agent presence check (>=1 active agent in target cluster). * Every sub-check wrapped in a wall-clock timeout to bound impact on the API event loop. RBAC: ssl.read for run, ssl.read for events. Per-user 5/min rate limit on both run and rerun, backed by the (user_id, action, created_at DESC) composite index. Frontend (`frontend/src/components/ACMEAutomation.js`): * "Diagnose" button on every order row + the existing "stuck order" warning row. * Modal with two tabs: - Pre-flight Checks (Antd Table with status pills + Re-run buttons + humanized error banner) - Event Log (Antd Timeline with auto-tail polling, scroll- to-bottom, pause-on-hover) * Correlation IDs surfaced in error banners and individual check fail details for backend-log lookup. ------------------------------------------------------------------ HEADLINE FEATURE B — Site Setup Wizard (Issue #14) ------------------------------------------------------------------ A single guided flow that creates a Backend + Servers + HTTP Frontend (and optional HTTPS Frontend) in one atomic transaction. Endpoints (`backend/routers/site_wizard.py`): POST /api/site-wizard/preview — diff-preview the changeset POST /api/site-wizard/create — atomic execute POST /api/site-wizard/reject — clean rollback (including any wizard_staged ACME orders) GET /api/site-wizard/drafts — draft persistence PUT /api/site-wizard/drafts/{id} — save/update DELETE /api/site-wizard/drafts/{id} Feature surface: * One screen captures both backend (mode + servers) AND frontend (http + optional https + SSL mode) inputs. * SSL modes: ACME (new order, HTTP-01 only for v1.5.0), Upload (existing PEM), Existing (link to a stored cert), or None. * ACME-staged path: wizard_staged_until watermark on the `letsencrypt_orders` row defers finalisation until agent confirmation; per-mode reject cleanly cancels and rolls back the staged order. * Live diff preview against the cluster's current generated config (renderer-evolution noise stripped — track-sc<N> dedup, per-server cookie strip, defaults-cookie inheritance, listen-block flattening). * Draft persistence with PEM stripped at save time (private keys never round-trip through the drafts table). * Per-cluster multi-tenancy: drafts and wizard_staged orders are isolated to the creating user's cluster scope. Frontend (`frontend/src/components/SiteWizard.js`): * 4-step Antd Steps flow: Backend → Frontend → SSL → Review. * Render the live diff preview inline before commit. * Antd Form-level validation mirrors backend Pydantic validators (numeric bounds, HAProxy reserved keywords, ALPN consistency, IPv6 scope-id, domain regex, server name dedup). ------------------------------------------------------------------ AUDIT CAMPAIGN — Rounds 1 → 22 (Bulgu #1 → #82) ------------------------------------------------------------------ v1.5.0 includes 22 adversarial review passes. Each round produced its own commit set in the corporate development line; this squash collapses those into the v1.5.0 release artefact. Highlights: Round 1-4 Site Wizard core: dry-run parity, single-line value injection guard, ACL -f pattern-file block, SSL parity, timeout regex, form-state pin. Round 5-7 defaults-cookie inheritance, server-named-cookie guard, fe/be mode mismatch, duplicate server names, health_check_uri + server_address validators. Round 8-10 cookie_name / cookie_options newline-injection guard, dry-run parity (round 9), TCP-mode HTTP-only feature blockers. Round 11 SSL name path traversal + health-check >= 1. Round 12-13 SSL & ACME deep dive (Bulgu #23-#32). Round 14 single-line value injection (Bulgu #33). Round 15-17 ACME multi-tenant UX, numeric bounds, HAProxy reserved keywords, ALPN/TLS consistency, all-backup, multi-domain & multi-user enterprise edges, drain/HSTS/post-completion (Bulgu #34-#53). Round 18-21 concurrency, agent state, TCP-mode HTTP-only, list size caps, IPv6 scope-id, preview account validation, TCP backend + balance uri reject (Bulgu #54-#61). Round 22 FE error visibility + 3x stale-data lockouts, referential integrity + cascade safety, authentication & authorization, multi-cluster isolation, apply_pending_changes concurrency, script injection + bulk import multi-tenancy, prefix-stripped signature comparison (Bulgu #62-#82). ------------------------------------------------------------------ NO CORPORATE-SPECIFIC ARTIFACTS ------------------------------------------------------------------ This squash deliberately sanitises corporate hostnames, container registry references, and TLS secret names into generic placeholders (`your-registry.example.com/your-org`, `haproxy-openmanager*.example.com`, `wildcard-tls`, `taylanbakircioglu/haproxy-openmanager-*`) so the public artefact contains no internal infrastructure detail. Pilot / development history that retained those values stays in the corporate fork and is NOT part of this commit. |
||
|
|
71c717364c |
fix: allow dot character in entity names for UI and backend validation
Bulk import accepted dots in frontend/backend/server names but UI and backend validators rejected them with ^[a-zA-Z0-9_-]+$. After import, entities with dots could not be edited. HAProxy itself allows dots in section names, so the regex is expanded to ^[a-zA-Z0-9_.-]+$ across all 12 validation points (5 React form rules, 1 ACL char-strip, 3 Pydantic validators, 1 WAF validator, 2 config-validator warnings). |
||
|
|
c2766eadbd |
feat: dark mode support, UI improvements, and version bump to v1.2.0
- Full dark mode support across all pages with lightbulb toggle in header - Theme preference persisted in localStorage across sessions - Ant Design 5 token-based theming (40+ components updated) - Recharts dark mode: axes, grids, tooltips adapt to theme - Login page redesigned with product-consistent blue-gray palette - Overscroll bounce background matches dark theme - All Servers search with multi-field filtering - Bulk Config Import UI streamlined with collapsible guidelines - ConfigProvider moved above AppContent for correct token resolution Made-with: Cursor |
||
|
|
93d7ad8fdb |
feat: add ACME Auto SSL with Let's Encrypt integration (v1.1.0)
Add automated SSL certificate management via ACME protocol (RFC 8555): - Full ACME client implementation (account registration, HTTP-01 challenges, certificate issuance/renewal) - Configurable ACME providers (Let's Encrypt, ZeroSSL, custom CA) via Settings UI - Auto-renewal scheduler with PENDING -> Apply -> APPLIED flow alignment - ACME account management (register, deactivate) from UI - Certificate request wizard with domain validation and cluster targeting - Zero changes to HAProxy agent scripts - challenges routed through existing architecture - Comprehensive security hardening (no private key exposure in API responses) - Full backward compatibility with existing SSL, Apply, Rollback, and Restore workflows - Updated README, API documentation, and Kubernetes deployment notes - Version management embedded in code (v1.1.0) - UI messaging improvements for agent-pull architecture accuracy Made-with: Cursor |
||
|
|
7d3eeebcb7 |
fix(waf): Require frontend selection with backend + frontend validation
COMPLETE UX FIX: Backend validation + Frontend required field Changes Summary: 1. Backend API validation (waf.py) 2. Frontend API validation (frontend.py) 3. Frontend UI required field (WAFManagement.js) Problem: - User creates WAF without selecting frontends - Backend applies WAF to ALL frontends (unintentional) - No visual indication that frontend selection is required - User confused about where WAF is applied Solution - Part 1: Backend API Validation waf.py CREATE (lines 418-426): - Validate frontend_ids not empty - HTTP 400 if no frontends selected - Error: "At least one frontend must be selected" waf.py UPDATE (lines 686-693): - Validate if frontend_ids explicitly provided - HTTP 400 if trying to clear all frontends - Allow config-only updates (preserve frontends) Solution - Part 2: Frontend Validation frontend.py CREATE (lines 408-428): - Validate backend has active servers - HTTP 400 if backend has no servers - Error: "Backend has no active servers. Add servers first." frontend.py UPDATE (lines 650-670): - Same validation when changing default_backend - Prevent routing to DOWN backends Solution - Part 3: Frontend UI (User Experience) WAFManagement.js (lines 1473-1508): BEFORE: - Label: "Target Frontends" - Tooltip: "Can be left empty for globally available WAF" - Placeholder: "Select frontends" - No validation - Optional field appearance AFTER: - Label: "Target Frontends" (with red asterisk) - Required validation rules: * Antd required: true * Custom validator: at least 1 frontend - Placeholder: "Select frontends (Required *)" - Tooltip: "At least one frontend is required" - Search enabled for easy filtering - Error messages: * "Please select at least one frontend" * "At least one frontend must be selected for WAF rule" User Experience Improvements: 1. Visual indication: Red asterisk on label 2. Clear placeholder text: "(Required *)" 3. Helpful tooltip: Explains requirement 4. Client-side validation: Immediate feedback 5. Server-side validation: Safety net 6. Searchable dropdown: Easy to find frontends 7. Clear error messages: User knows what to do Test Scenarios: 1. Create WAF without selecting frontend: - UI: Red error "Please select at least one frontend" - Submit blocked (client-side) 2. Bypass client-side, try API: - API: HTTP 400 "At least one frontend must be selected" 3. Create frontend with server-less backend: - UI: Can select backend - API: HTTP 400 "Backend has no active servers" 4. Update WAF remove all frontends: - UI: Red error message - API: HTTP 400 if bypassed Related: bcb8ef0 (backend without servers) Refs: #waf-validation #frontend-validation #ux-improvement |
||
|
|
8c4d7c246c |
Fix: Cross-cluster data bleeding + Enhanced SSL dropdown UI
🐛 Critical Cross-Cluster Data Bleeding - System-Wide Fix: Fixed old cluster's data appearing when switching clusters across 4 components Root Cause: - User switches from Cluster A to Cluster B - Old cluster data remains in React state during API fetch - Race condition: UI shows Cluster A data while fetching Cluster B - Backend page: Data persisted after fetch - Frontend page: Data briefly appeared then disappeared ✅ Components Fixed (State Clearing on Cluster Change): 1. BackendServers.js (Line 115-122) - Clear: backends, filteredBackends, frontends, sslCertificates 2. FrontendManagement.js (Line 150-157) - Clear: frontends, filteredFrontends, backends, sslCertificates 3. WAFManagement.js (Line 277-282) - Clear: rules, filteredRules, frontends 4. DashboardV2.js (Line 402-407) - Clear: statsData, frontendOptions, backendOptions, backendHealth, slowestBackends Already Had State Clearing: ✓ SSLManagement.js ✓ AgentManagement.js ✓ Configuration.js ✓ ApplyManagement.js ✨ UI Enhancement: Backend Server SSL Dropdown Redesigned to match Frontend SSL dropdown design: Before: star-burgan-com-tr - *.burgan.com.tr (Expires: 2/25/2026) After: star-burgan-com-tr - *.burgan.com.tr [🌍 Global] ✅ (125 days) demo-cert - *.apps.cluster.example.com [📍 Cluster] ✅ (1502 days) Features Added: ✅ Status icons: valid, ⚠️ expiring soon, ❌ expired ✅ Days until expiry countdown ✅ SSL type tags: 🌍 Global (blue) or 📍 Cluster (green) ✅ Better layout with flex spacing ✅ optionLabelProp for compact selected view 🎯 Impact Analysis - All Components Safe: Tested 8 components with selectedCluster dependency: ✓ BackendServers - State clearing added ✓ FrontendManagement - State clearing added ✓ WAFManagement - State clearing added ✓ DashboardV2 - State clearing added ✓ SSLManagement - Already had clearing ✓ AgentManagement - Already had clearing ✓ Configuration - Already had clearing ✓ ApplyManagement - Already had clearing No Breaking Changes: - Only added state clearing in useEffect - Fetch logic unchanged - Response handling unchanged - UI components unchanged (except SSL dropdown enhancement) ✅ Cross-cluster data bleeding completely resolved |
||
|
|
199ade8ce5 |
Fix: Browser cache causing phantom deleted entities across all pages
🐛 Critical Browser Cache Bug - System-Wide Fix: - Fixed deleted entities reappearing on normal page refresh - Hard refresh (Cmd+Shift+R) worked, normal refresh showed stale cache data - Applied cache-busting to ALL entity fetch operations across entire application 🔧 Cache-Control Headers Added to 10 Components: 1. BackendServers.js - fetchBackends(), fetchFrontends(), fetchSSLCertificates() 2. FrontendManagement.js - fetchFrontends(), fetchBackends(), fetchSSLCertificates() 3. SSLManagement.js - fetchCertificates() 4. ApplyManagement.js - fetchPendingChanges() (4 API calls: frontends, backends, WAF, SSL) 5. WAFManagement.js - fetchFrontends() 6. AgentManagement.js - fetchAgents(), fetchPools() 7. PoolManagement.js - fetchPools(), fetchPoolAgents() 8. UserManagement.js - fetchUsers() 9. Configuration.js - fetchAgents() 10. ClusterContext.js - fetchClusters() Headers Applied: 'Cache-Control': 'no-cache, no-store, must-revalidate' 'Pragma': 'no-cache' 'Expires': '0' (some components) 🎯 Impact Analysis - SAFE Changes: ✅ Only GET requests affected (POST/PUT/DELETE unchanged) ✅ Response format unchanged (only headers added to request) ✅ No breaking changes to existing functionality ✅ Performance impact minimal (entities change frequently anyway) 🛡️ Protected Against Cache: - Deleted backends/frontends won't reappear - Deleted agents won't show in lists - SSL certificates always fresh - User list always current - Cluster/Pool data always accurate 🔍 Testing Performed: - Backend API verified: Only active backends returned (is_active=TRUE) - SSL API verified: Returns 4 certificates correctly - All axios.get calls now have cache-control headers - No linter errors ✅ Root Cause Solved: Browser/Axios caching GET responses → Stale data on normal refresh Solution: Force fresh data from API on every request Impact: Phantom entities bug completely resolved across entire application |
||
|
|
6aae0f4309 | Initial commit |