7 Commits

Author	SHA1	Message	Date
Shaun Arman	bdb63f3aee	fix: resolve clippy uninlined_format_args in integrations and related modules ... Replace format!("msg: {}", var) with format!("msg: {var}") across 8 files to satisfy the uninlined_format_args lint (-D warnings) in CI run 178. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>	2026-04-04 12:27:26 -05:00
Shaun Arman	a7903db904	fix: persist integration settings and implement persistent browser windows ... ## Integration Settings Persistence - Add database commands to save/load integration configs (base_url, username, project_name, space_key) - Frontend now loads configs from DB on mount and saves changes automatically - Fixes issue where settings were lost on app restart ## Persistent Browser Window Architecture - Integration browser windows now stay open for user browsing and authentication - Extract fresh cookies before each API call to handle token rotation - Track open windows in app state (integration_webviews HashMap) - Windows titled as "{Service} Browser (TFTSR)" for clarity - Support easy navigation between app and browser windows (Cmd+Tab/Alt+Tab) - Gracefully handle closed windows with automatic cleanup ## Bug Fixes - Fix Rust formatting issues across 8 files - Fix clippy warnings: - Use is_some_and() instead of map_or() in openai.rs - Use .to_string() instead of format!() in integrations.rs - Add missing OptionalExtension import for .optional() method ## Tests - Add test_integration_config_serialization - Add test_webview_tracking - Add test_token_auth_request_serialization - All 6 integration tests passing ## Files Modified - src-tauri/src/state.rs: Add integration_webviews tracking - src-tauri/src/lib.rs: Register 3 new commands, initialize webviews HashMap - src-tauri/src/commands/integrations.rs: Config persistence, fresh cookie extraction (+151 lines) - src-tauri/src/integrations/webview_auth.rs: Persistent window behavior - src/lib/tauriCommands.ts: TypeScript wrappers for new commands - src/pages/Settings/Integrations.tsx: Load/save configs from DB Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-04-04 09:57:22 -05:00
Shaun Arman	fbce897608	feat: complete webview cookie extraction implementation ... Implement working cookie extraction using Tauri's IPC event system: **How it works:** 1. Opens embedded browser window for user to login 2. User completes authentication (including SSO) 3. User clicks "Complete Login" button in UI 4. JavaScript injected into webview extracts `document.cookie` 5. Parsed cookies emitted via Tauri event: `tftsr-cookies-extracted` 6. Rust listens for event and receives cookie data 7. Cookies encrypted and stored in database **Technical implementation:** - Uses `window.__TAURI__.event.emit()` from injected JavaScript - Rust listens via `app_handle.listen()` with Listener trait - 10-second timeout with clear error messages - Handles empty cookies and JavaScript errors gracefully - Cross-platform compatible (no platform-specific APIs) **Cookie limitations:** - `document.cookie` only exposes non-HttpOnly cookies - HttpOnly session cookies won't be captured via JavaScript - For HttpOnly cookies, services must provide API tokens as fallback Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-04-03 17:31:48 -05:00
Shaun Arman	32d83df3cf	feat: add multi-mode authentication for integrations (v0.2.10) ... Implement three authentication methods for Confluence, ServiceNow, and Azure DevOps: 1. **OAuth2** - Traditional OAuth flow for enterprise SSO environments 2. **Embedded Browser** - Webview-based login that captures session cookies/tokens - Solves VPN constraints: users authenticate off-VPN via web UI - Extracted credentials work on-VPN for API calls - Based on confluence-publisher agent pattern 3. **Manual Token** - Direct API token/PAT input as fallback **Changes:** - Add webview_auth.rs module for embedded browser authentication - Implement authenticate_with_webview and extract_cookies_from_webview commands - Implement save_manual_token command with validation - Add AuthMethod enum to support all three modes - Add RadioGroup UI component for mode selection - Complete rewrite of Integrations settings page with mode-specific UI - Add secondary button variant for UI consistency **VPN-friendly design:** Users can authenticate via webview when off-VPN (web UI accessible), then use extracted cookies for API calls when on-VPN (API requires VPN). Addresses enterprise SSO limitations where OAuth app registration is blocked. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-04-03 17:26:09 -05:00
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