3 Commits

Author	SHA1	Message	Date
Shaun Arman	05f4b51370	feat: implement OAuth2 callback server with automatic token exchange ... Phase 2.2: OAuth2 flow - Part 3 (Callback server) COMPLETE ✅ Implemented: - Local HTTP server on localhost:8765 using warp * GET /callback?code=...&state=... - OAuth redirect handler * GET /health - Health check endpoint * Graceful shutdown with oneshot channel - Automatic callback handling * Server auto-starts on first initiate_oauth call * Background task listens for OAuth redirects * Automatically exchanges code for token * Stores encrypted token in database * Logs audit event for each successful OAuth - Updated initiate_oauth command * Starts callback server if not running * Stores (service, verifier) tuple in OAuth state * Returns auth URL to open in browser/webview - Updated handle_oauth_callback_internal * Accepts AppState reference (not State) * Called automatically by callback server * Exchanges code, encrypts token, stores in DB - Beautiful success/error HTML pages * Green checkmark on success * Auto-closes window after 3 seconds * Clear error messages on failure - Global state management * OAUTH_STATE: Maps state key -> (service, verifier) * CALLBACK_SERVER_SHUTDOWN: Holds shutdown channel * Thread-safe with Mutex wrappers Dependencies added: - warp 0.3 - Lightweight HTTP framework TDD tests (7 passing with --test-threads=1): Callback server tests: * Health endpoint verification * Callback parameter parsing * Missing/partial parameter handling * Graceful shutdown Integration command tests: * OAuth state storage and retrieval * Multiple key management * OAuthInitResponse serialization COMPLETE OAUTH2 FLOW: 1. User calls initiate_oauth("confluence") 2. Callback server starts (if not running) 3. Frontend receives auth URL 4. User opens URL in browser/webview 5. User authorizes, redirected to localhost:8765/callback?code=... 6. Callback server receives redirect 7. Token exchanged automatically 8. Token encrypted and stored in DB 9. Success page shown to user 10. Window auto-closes Next: Frontend components (AuthWindow, Settings UI, CSP updates)	2026-04-03 14:59:39 -05:00
Shaun Arman	75302a1cc7	feat: add OAuth2 Tauri commands for integration authentication ... Phase 2.2: OAuth2 flow - Part 2 (Tauri commands) Implemented: - initiate_oauth command * Generates PKCE challenge * Creates state key for OAuth session * Stores verifier in global OAuth state * Returns authorization URL for Confluence/ADO * ServiceNow uses basic auth (not OAuth2) - handle_oauth_callback command * Retrieves and removes verifier from state * Exchanges authorization code for access token * Encrypts and stores token in DB * Logs audit event for successful OAuth - OAuthInitResponse type for frontend * auth_url: Full OAuth authorization URL * state: Session key for callback matching - Global OAUTH_STATE storage (lazy_static) * Thread-safe HashMap for PKCE verifiers * Temporary storage during OAuth flow * Automatically cleaned up after exchange Service configuration: - Confluence: auth.atlassian.com OAuth2 - Azure DevOps: login.microsoftonline.com OAuth2 - ServiceNow: Basic auth (not OAuth2) Client IDs from env vars: - CONFLUENCE_CLIENT_ID - ADO_CLIENT_ID Dependencies added: - lazy_static 1.4 - Global static initialization TDD tests (3 passing): - OAuth state storage and retrieval - Multiple key management - OAuthInitResponse serialization Commands registered in lib.rs generate_handler![] Next: Local HTTP callback server for OAuth redirects	2026-04-03 14:50:13 -05:00
Shaun Arman	8839075805	feat: initial implementation of TFTSR IT Triage & RCA application ... Implements Phases 1-8 of the TFTSR implementation plan. Rust backend (Tauri 2.x, src-tauri/): - Multi-provider AI: OpenAI-compatible, Anthropic, Gemini, Mistral, Ollama - PII detection engine: 11 regex patterns with overlap resolution - SQLCipher AES-256 encrypted database with 10 versioned migrations - 28 Tauri IPC commands for triage, analysis, document, and system ops - Ollama: hardware probe, model recommendations, pull/delete with events - RCA and blameless post-mortem Markdown document generators - PDF export via printpdf - Audit log: SHA-256 hash of every external data send - Integration stubs for Confluence, ServiceNow, Azure DevOps (v0.2) Frontend (React 18 + TypeScript + Vite, src/): - 9 pages: full triage workflow NewIssue→LogUpload→Triage→Resolution→RCA→Postmortem→History+Settings - 7 components: ChatWindow, TriageProgress, PiiDiffViewer, DocEditor, HardwareReport, ModelSelector, UI primitives - 3 Zustand stores: session, settings (persisted), history - Type-safe tauriCommands.ts matching Rust backend types exactly - 8 IT domain system prompts (Linux, Windows, Network, K8s, DB, Virt, HW, Obs) DevOps: - .woodpecker/test.yml: rustfmt, clippy, cargo test, tsc, vitest on every push - .woodpecker/release.yml: linux/amd64 + linux/arm64 builds, Gogs release upload Verified: - cargo check: zero errors - tsc --noEmit: zero errors - vitest run: 13/13 unit tests passing Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>	2026-03-14 22:36:25 -05:00