94 lines
3.4 KiB
Markdown
94 lines
3.4 KiB
Markdown
# Development Authentication Setup
|
|
|
|
## Quick Fix for Sign-In Issues
|
|
|
|
Your authentication system has been updated to be more development-friendly. Here are the changes made:
|
|
|
|
### 1. CSRF Token Handling Fixed
|
|
|
|
- **Frontend**: Added automatic CSRF token fetching and inclusion in API requests
|
|
- **Backend**: Added development bypass for CSRF protection
|
|
- **CORS**: Added `X-CSRF-Token` to allowed headers
|
|
|
|
### 2. Development Environment Variables
|
|
|
|
Add these to your `.env` file to simplify development:
|
|
|
|
```bash
|
|
# Disable CSRF protection for easier development
|
|
DISABLE_CSRF=true
|
|
|
|
# Disable rate limiting for development
|
|
DISABLE_RATE_LIMIT=true
|
|
|
|
# Disable account locking for development
|
|
DISABLE_ACCOUNT_LOCKING=true
|
|
|
|
# Enable detailed error messages
|
|
EXPOSE_VALIDATION_ERRORS=true
|
|
|
|
# CORS configuration
|
|
CORS_ORIGIN=http://localhost:3000
|
|
```
|
|
|
|
### 3. What Was Complex About Your Auth System
|
|
|
|
Your authentication system had several layers of security that, while production-ready, made development difficult:
|
|
|
|
1. **CSRF Protection**: Double-submit cookie pattern with session/user binding
|
|
2. **Rate Limiting**: 5 login attempts per 15 minutes per IP+UA
|
|
3. **Account Locking**: Exponential backoff on failed login attempts
|
|
4. **Extensive Audit Logging**: Every auth event logged with full context
|
|
5. **Multiple Auth Strategies**: JWT + Local + Session management
|
|
6. **Complex Error Handling**: Secure error mapping to prevent information leakage
|
|
|
|
### 4. Simplified Development Flow
|
|
|
|
With the new configuration:
|
|
|
|
1. **CSRF tokens are automatically handled** by the frontend API client
|
|
2. **Development bypasses** can be enabled via environment variables
|
|
3. **Better error messages** in development mode
|
|
4. **Exempt paths** include all necessary auth endpoints
|
|
|
|
### 5. Production Security Maintained
|
|
|
|
All security features remain intact for production:
|
|
- Set `DISABLE_CSRF=false` or remove the variable
|
|
- Set `DISABLE_RATE_LIMIT=false` or remove the variable
|
|
- Set `DISABLE_ACCOUNT_LOCKING=false` or remove the variable
|
|
|
|
### 6. Testing the Fix
|
|
|
|
1. Restart your backend server
|
|
2. Try logging in through the frontend
|
|
3. Check the browser network tab to see requests going to `/api/auth/login`
|
|
4. Check server logs for CSRF bypass messages (if debug enabled)
|
|
|
|
### 6.1. Core API Configuration Fix - The Real Issue
|
|
|
|
**Root Cause**: The frontend code was inconsistent with OpenAPI generated types.
|
|
|
|
- **OpenAPI Types**: Expect paths like `/api/auth/login` (with `/api` prefix)
|
|
- **Frontend Code**: Was calling paths like `/auth/login` (without `/api` prefix)
|
|
- **Workaround**: `normalizePath` function was adding `/api` prefix automatically
|
|
|
|
**Proper Fix Applied**:
|
|
1. **Removed Path Normalization**: Eliminated the `normalizePath` function entirely
|
|
2. **Fixed Frontend Calls**: Updated all API calls to use correct OpenAPI paths with `/api` prefix
|
|
3. **Base URL Correction**: Set base URL to `http://localhost:4000` (without `/api`)
|
|
4. **Router Configuration**: Added SecurityModule to API routes
|
|
|
|
**Result**: Clean, consistent API calls that match the OpenAPI specification exactly.
|
|
|
|
### 7. If Issues Persist
|
|
|
|
Check these common issues:
|
|
|
|
1. **CORS Configuration**: Ensure `CORS_ORIGIN` matches your frontend URL
|
|
2. **Cookie Settings**: Ensure cookies are being set and sent properly
|
|
3. **Network Tab**: Check if CSRF token requests are successful
|
|
4. **Server Logs**: Look for detailed error messages with the new logging
|
|
|
|
The authentication system is now much more developer-friendly while maintaining production security standards.
|