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>
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>
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)
