mirror of
https://github.com/AutoMaker-Org/automaker.git
synced 2026-02-04 09:13:08 +00:00
chore: remove unused files from codebase
This commit is contained in:
Kacper
@@ -1,24 +0,0 @@
|
|||||||
{
|
|
||||||
"sandbox": {
|
|
||||||
"enabled": true,
|
|
||||||
"autoAllowBashIfSandboxed": true
|
|
||||||
},
|
|
||||||
"permissions": {
|
|
||||||
"defaultMode": "acceptEdits",
|
|
||||||
"allow": [
|
|
||||||
"Read(./**)",
|
|
||||||
"Write(./**)",
|
|
||||||
"Edit(./**)",
|
|
||||||
"Glob(./**)",
|
|
||||||
"Grep(./**)",
|
|
||||||
"Bash(*)",
|
|
||||||
"mcp__puppeteer__puppeteer_navigate",
|
|
||||||
"mcp__puppeteer__puppeteer_screenshot",
|
|
||||||
"mcp__puppeteer__puppeteer_click",
|
|
||||||
"mcp__puppeteer__puppeteer_fill",
|
|
||||||
"mcp__puppeteer__puppeteer_select",
|
|
||||||
"mcp__puppeteer__puppeteer_hover",
|
|
||||||
"mcp__puppeteer__puppeteer_evaluate"
|
|
||||||
]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
@@ -1,134 +0,0 @@
|
|||||||
# Improved Error Handling for Rate Limiting
|
|
||||||
|
|
||||||
## Problem
|
|
||||||
|
|
||||||
When running multiple features concurrently in auto-mode, the Claude API rate limits were being exceeded, resulting in cryptic error messages:
|
|
||||||
|
|
||||||
```
|
|
||||||
Error: Claude Code process exited with code 1
|
|
||||||
```
|
|
||||||
|
|
||||||
This error provided no actionable information to users about:
|
|
||||||
|
|
||||||
- What went wrong (rate limit exceeded)
|
|
||||||
- How long to wait before retrying
|
|
||||||
- How to prevent it in the future
|
|
||||||
|
|
||||||
## Root Cause
|
|
||||||
|
|
||||||
The Claude Agent SDK was terminating with exit code 1 when hitting rate limits (HTTP 429), but the error details were not being properly surfaced to the user. The error handling code only showed the generic exit code message instead of the actual API error.
|
|
||||||
|
|
||||||
## Solution
|
|
||||||
|
|
||||||
Implemented comprehensive rate limit error handling across the stack:
|
|
||||||
|
|
||||||
### 1. Enhanced Error Classification (libs/utils)
|
|
||||||
|
|
||||||
Added new error type and detection functions:
|
|
||||||
|
|
||||||
- **New error type**: `'rate_limit'` added to `ErrorType` union
|
|
||||||
- **`isRateLimitError()`**: Detects 429 and rate_limit errors
|
|
||||||
- **`extractRetryAfter()`**: Extracts retry duration from error messages
|
|
||||||
- **Updated `classifyError()`**: Includes rate limit classification with retry-after metadata
|
|
||||||
- **Updated `getUserFriendlyErrorMessage()`**: Provides clear, actionable messages for rate limit errors
|
|
||||||
|
|
||||||
### 2. Improved Claude Provider Error Handling (apps/server)
|
|
||||||
|
|
||||||
Enhanced `ClaudeProvider.executeQuery()` to:
|
|
||||||
|
|
||||||
- Classify all errors using the enhanced error utilities
|
|
||||||
- Detect rate limit errors specifically
|
|
||||||
- Provide user-friendly error messages with:
|
|
||||||
- Clear explanation of the problem (rate limit exceeded)
|
|
||||||
- Retry-after duration when available
|
|
||||||
- Actionable tip: reduce `maxConcurrency` in auto-mode
|
|
||||||
- Preserve original error details for debugging
|
|
||||||
|
|
||||||
### 3. Comprehensive Test Coverage
|
|
||||||
|
|
||||||
Added 8 new tests covering:
|
|
||||||
|
|
||||||
- Rate limit error detection (429, rate_limit keywords)
|
|
||||||
- Retry-after extraction from various message formats
|
|
||||||
- Error classification with retry metadata
|
|
||||||
- User-friendly message generation
|
|
||||||
- Edge cases (null/undefined, non-rate-limit errors)
|
|
||||||
|
|
||||||
**Total test suite**: 162 tests passing ✅
|
|
||||||
|
|
||||||
## User-Facing Changes
|
|
||||||
|
|
||||||
### Before
|
|
||||||
|
|
||||||
```
|
|
||||||
[AutoMode] Feature touch-gesture-support failed: Error: Claude Code process exited with code 1
|
|
||||||
```
|
|
||||||
|
|
||||||
### After
|
|
||||||
|
|
||||||
```
|
|
||||||
[AutoMode] Feature touch-gesture-support failed: Rate limit exceeded (429). Please wait 60 seconds before retrying.
|
|
||||||
|
|
||||||
Tip: If you're running multiple features in auto-mode, consider reducing concurrency (maxConcurrency setting) to avoid hitting rate limits.
|
|
||||||
```
|
|
||||||
|
|
||||||
## Benefits
|
|
||||||
|
|
||||||
1. **Clear communication**: Users understand exactly what went wrong
|
|
||||||
2. **Actionable guidance**: Users know how long to wait and how to prevent future errors
|
|
||||||
3. **Better debugging**: Original error details preserved for technical investigation
|
|
||||||
4. **Type safety**: New `isRateLimit` and `retryAfter` fields properly typed in `ErrorInfo`
|
|
||||||
5. **Comprehensive testing**: All edge cases covered with automated tests
|
|
||||||
|
|
||||||
## Technical Details
|
|
||||||
|
|
||||||
### Files Modified
|
|
||||||
|
|
||||||
- `libs/types/src/error.ts` - Added `'rate_limit'` type and `retryAfter` field
|
|
||||||
- `libs/utils/src/error-handler.ts` - Added rate limit detection and extraction logic
|
|
||||||
- `libs/utils/src/index.ts` - Exported new utility functions
|
|
||||||
- `libs/utils/tests/error-handler.test.ts` - Added 8 new test cases
|
|
||||||
- `apps/server/src/providers/claude-provider.ts` - Enhanced error handling with user-friendly messages
|
|
||||||
|
|
||||||
### API Changes
|
|
||||||
|
|
||||||
**ErrorInfo interface** (backwards compatible):
|
|
||||||
|
|
||||||
```typescript
|
|
||||||
interface ErrorInfo {
|
|
||||||
type: ErrorType; // Now includes 'rate_limit'
|
|
||||||
message: string;
|
|
||||||
isAbort: boolean;
|
|
||||||
isAuth: boolean;
|
|
||||||
isCancellation: boolean;
|
|
||||||
isRateLimit: boolean; // NEW
|
|
||||||
retryAfter?: number; // NEW (seconds to wait)
|
|
||||||
originalError: unknown;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
**New utility functions**:
|
|
||||||
|
|
||||||
```typescript
|
|
||||||
isRateLimitError(error: unknown): boolean
|
|
||||||
extractRetryAfter(error: unknown): number | undefined
|
|
||||||
```
|
|
||||||
|
|
||||||
## Future Improvements
|
|
||||||
|
|
||||||
This PR lays the groundwork for future enhancements:
|
|
||||||
|
|
||||||
1. **Automatic retry with exponential backoff**: Use `retryAfter` to implement smart retry logic
|
|
||||||
2. **Global rate limiter**: Track requests to prevent hitting limits proactively
|
|
||||||
3. **Concurrency auto-adjustment**: Dynamically reduce concurrency when rate limits are detected
|
|
||||||
4. **User notifications**: Show toast/banner when rate limits are approaching
|
|
||||||
|
|
||||||
## Testing
|
|
||||||
|
|
||||||
Run tests with:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
npm run test -w @automaker/utils
|
|
||||||
```
|
|
||||||
|
|
||||||
All 162 tests pass, including 8 new rate limit tests.
|
|
||||||
File diff suppressed because it is too large
Load Diff
@@ -1,94 +0,0 @@
|
|||||||
# API Security Hardening Design
|
|
||||||
|
|
||||||
**Date:** 2025-12-29
|
|
||||||
**Branch:** protect-api-with-api-key
|
|
||||||
**Status:** Approved
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
Security improvements for the API authentication system before merging the PR. These changes harden the existing implementation for production deployment scenarios (local, Docker, internet-exposed).
|
|
||||||
|
|
||||||
## Fixes to Implement
|
|
||||||
|
|
||||||
### 1. Use Short-Lived wsToken for WebSocket Authentication
|
|
||||||
|
|
||||||
**Problem:** The client currently passes `sessionToken` in WebSocket URL query parameters. Query params get logged and can leak credentials.
|
|
||||||
|
|
||||||
**Solution:** Update the client to:
|
|
||||||
|
|
||||||
1. Fetch a wsToken from `/api/auth/token` before each WebSocket connection
|
|
||||||
2. Use `wsToken` query param instead of `sessionToken`
|
|
||||||
3. Never put session tokens in URLs
|
|
||||||
|
|
||||||
**Files to modify:**
|
|
||||||
|
|
||||||
- `apps/ui/src/lib/http-api-client.ts` - Update `connectWebSocket()` to fetch wsToken first
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 2. Add Environment Variable to Hide API Key from Logs
|
|
||||||
|
|
||||||
**Problem:** The API key is printed to console on startup, which gets captured by logging systems in production.
|
|
||||||
|
|
||||||
**Solution:** Add `AUTOMAKER_HIDE_API_KEY=true` env var to suppress the banner.
|
|
||||||
|
|
||||||
**Files to modify:**
|
|
||||||
|
|
||||||
- `apps/server/src/lib/auth.ts` - Wrap console.log banner in env var check
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 3. Add Rate Limiting to Login Endpoint
|
|
||||||
|
|
||||||
**Problem:** No brute force protection on `/api/auth/login`. Attackers could attempt many API keys.
|
|
||||||
|
|
||||||
**Solution:** Add basic in-memory rate limiting:
|
|
||||||
|
|
||||||
- ~5 attempts per minute per IP
|
|
||||||
- In-memory Map tracking (resets on server restart)
|
|
||||||
- Return 429 Too Many Requests when exceeded
|
|
||||||
|
|
||||||
**Files to modify:**
|
|
||||||
|
|
||||||
- `apps/server/src/routes/auth/index.ts` - Add rate limiting logic to login handler
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 4. Use Timing-Safe Comparison for API Key
|
|
||||||
|
|
||||||
**Problem:** Using `===` for API key comparison is vulnerable to timing attacks.
|
|
||||||
|
|
||||||
**Solution:** Use `crypto.timingSafeEqual()` for constant-time comparison.
|
|
||||||
|
|
||||||
**Files to modify:**
|
|
||||||
|
|
||||||
- `apps/server/src/lib/auth.ts` - Update `validateApiKey()` function
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 5. Make WebSocket Tokens Single-Use
|
|
||||||
|
|
||||||
**Problem:** wsTokens can be reused within the 5-minute window. If intercepted, attackers have time to use them.
|
|
||||||
|
|
||||||
**Solution:** Delete the token after first successful validation.
|
|
||||||
|
|
||||||
**Files to modify:**
|
|
||||||
|
|
||||||
- `apps/server/src/lib/auth.ts` - Update `validateWsConnectionToken()` to delete after use
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Implementation Order
|
|
||||||
|
|
||||||
1. Fix #4 (timing-safe comparison) - Simple, isolated change
|
|
||||||
2. Fix #5 (single-use wsToken) - Simple, isolated change
|
|
||||||
3. Fix #2 (hide API key env var) - Simple, isolated change
|
|
||||||
4. Fix #3 (rate limiting) - Moderate complexity
|
|
||||||
5. Fix #1 (client wsToken usage) - Requires coordination with server
|
|
||||||
|
|
||||||
## Testing Notes
|
|
||||||
|
|
||||||
- Test login with rate limiting (verify 429 after 5 attempts)
|
|
||||||
- Test WebSocket connection with new wsToken flow
|
|
||||||
- Test wsToken is invalidated after first use
|
|
||||||
- Verify `AUTOMAKER_HIDE_API_KEY=true` suppresses banner
|
|
||||||
Reference in New Issue
Block a user