Skip to content

A
aisbf
Commit 483b2f62 authored by Your Name's avatar Your Name
Browse files
Options

Restore missing markdown

parent f182fbd1
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 0 additions and 4785 deletions
CHANGES.md deleted 100644 → 0
View file @ f182fbd1
# AISBF v0.99.33 - Changes Summary
## Fixed Issues
### 1. Analytics Token Counting for Kilo/Kilocode Providers
- **Problem**: Kilo providers return OpenAI `ChatCompletion` objects instead of dict responses, causing analytics to fail silently
- **Solution**: Added support for both dict and ChatCompletion object responses in analytics.py
- **Files Modified**: `aisbf/analytics.py`, `aisbf/handlers.py`
### 2. Database Migration for Missing Columns
- **Problem**: `token_usage` table was missing 4 columns: `success`, `latency_ms`, `error_type`, `token_id`
- **Solution**: Fixed migration code to run on startup and add all missing columns automatically
- **Files Modified**: `aisbf/database.py`
### 3. Model Retrieval from lisa.nexlab.net
- **Problem**: Missing `handle_model_list` method caused model retrieval to fail
- **Solution**: Restored handlers.py from git and added proper model list handling
- **Files Modified**: `aisbf/handlers.py`
### 4. Response Cache Serialization
- **Problem**: Cache failed to serialize ChatCompletion objects
- **Solution**: Added automatic object → dict conversion for response cache
- **Files Modified**: `aisbf/cache.py`
### 5. MySQL Timezone Issues
- **Problem**: Analytics queries used `.isoformat()` instead of UTC formatted timestamps, causing blank graphs on MySQL
- **Solution**: All timestamp queries now use `_format_timestamp()` method for proper UTC formatting
- **Files Modified**: `aisbf/analytics.py`
### 6. Cost Calculation Debug Logging
- **Problem**: Cost calculation breakdown was at DEBUG level and never called
- **Solution**:
- Changed all cost logging to INFO level
- Added cost calculation call in handlers.py success path
- Added kilo providers to DEFAULT_PRICING with $0.00 (subscription/free)
- **Files Modified**: `aisbf/analytics.py`, `aisbf/handlers.py`
### 7. Database Tracking Debug Logging
- **Problem**: Insufficient logging to debug tracking issues
- **Solution**: Added comprehensive trace logging for all database insert operations
- **Files Modified**: `aisbf/database.py`
### 8. Analytics Time Range Filter
- **Problem**: Analytics page lacked "Yesterday" option and proper time range handling
- **Solution**:
- Added "Yesterday" preset option
- Improved time range handling in both frontend and backend
- Fixed custom date range logic
- Fixed graph title to dynamically show selected time range
- **Files Modified**: `templates/dashboard/analytics.html`, `main.py`, `aisbf/analytics.py`
### 9. Analytics Filters Not Applied to All Sections
- **Problem**: Cost overview, model performance, and recommendations ignored time range filters
- **Solution**:
- Added `from_datetime` and `to_datetime` parameters to `get_model_performance()`
- Added `from_datetime` and `to_datetime` parameters to `get_optimization_recommendations()`
- Model performance now uses date-filtered provider stats
- All analytics sections now respect the selected time range
- **Files Modified**: `aisbf/analytics.py`, `main.py`
### 10. Cost Overview Hardcoded to 24 Hours
- **Problem**: Cost overview always showed last 24 hours regardless of selected time range
- **Solution**: Simplified logic to use tokens from provider stats which already respect date range
- **Files Modified**: `aisbf/analytics.py`
### 11. Model Performance Shows No Data
- **Problem**: `context_dimensions` table remained empty because `record_context_dimension` was never called
- **Solution**:
- Added fallback logic to query `token_usage` table when `context_dimensions` is empty
- Added context dimension recording in request success path
- Model performance now displays data even on fresh installations
- **Files Modified**: `aisbf/analytics.py`, `aisbf/handlers.py`
### 12. Deprecated Database Function
- **Problem**: Using deprecated `get_database()` function causing warnings
- **Solution**: Replaced with `DatabaseRegistry.get_config_database()`
- **Files Modified**: `aisbf/handlers.py`
### 13. Model Performance Type Column Generic
- **Problem**: Type column showed generic "Provider Model" instead of actual provider type
- **Solution**: Added provider_type field from config (shows Kilo, Claude, Qwen, Codex, etc.)
- **Files Modified**: `aisbf/analytics.py`, `templates/dashboard/analytics.html`
### 14. OAuth2 Signup Blocked by API Authentication
- **Problem**: When API authentication is enabled, OAuth2 signup/login endpoints returned 401 error
- **Solution**: Added `/auth/` path exclusion to authentication middleware
- **Files Modified**: `main.py`
## New Features
### Enhanced Debug Logging
All tracking operations now log:
- Full parameter dump for every database insert
- SQL queries being executed
- Number of rows affected
- Full traceback on errors
- Cost calculation breakdown with 8 decimal precision
### Time Range Options
Analytics page now supports:
- Last 1 Hour
- Last 6 Hours
- Last 24 Hours (Default)
- Yesterday (NEW)
- Last 7 Days
- Last 30 Days
- Last 90 Days
- Custom Range (with date/time pickers)
Graph title and all analytics sections dynamically update based on selected range.
### Model Performance Tracking
- Automatically records context dimensions on each request
- Falls back to token_usage data when context_dimensions is empty
- Shows performance metrics for all providers with activity in selected time range
- Displays actual provider type (Kilo, Claude, Qwen, etc.) in Type column
## Backwards Compatibility
All changes maintain 100% backwards compatibility:
- Fallback INSERT logic for old database schemas
- Support for both dict and object responses
- All existing providers continue to work
- Streaming requests remain functional
## Version Updates
Updated version to `0.99.33` in:
- `aisbf/__init__.py`
- `pyproject.toml`
- `setup.py`
## Testing Recommendations
1. Verify model retrieval from lisa.nexlab.net works correctly
2. Test analytics data displays correctly in web dashboard with MySQL
3. Confirm cost calculations show in logs for all provider types
4. Test "Yesterday" time range filter
5. Verify database migrations work on live MySQL instances
6. Test all existing providers (kiro-cli, claude, qwen, codex, kilo)
7. Verify graph title updates correctly for each time range selection
8. Confirm model performance shows data for selected time range
9. Verify cost overview reflects selected time period
10. Check that recommendations are based on filtered time range data
11. Test model performance displays on fresh installations with empty context_dimensions table
12. Verify no deprecation warnings in logs
13. Confirm model performance Type column shows correct provider types
14. Test OAuth2 signup/login works with API authentication enabled
COMPLETE_SUMMARY.md deleted 100644 → 0
View file @ f182fbd1
This diff is collapsed.
DATABASE_MIGRATION.md deleted 100644 → 0
View file @ f182fbd1
# AISBF Database Migration Guide
## Overview
AISBF uses two separate SQLite databases with distinct purposes:
1. **`aisbf.db`** - Configuration and persistent data
2. **`cache.db`** - Temporary caching only
## Database Separation
### aisbf.db (Configuration Database)
This database contains all configuration and persistent data:
**User Management:**
- `users` - User accounts and authentication
- `user_api_tokens` - API tokens for users
- `user_providers` - User-specific provider configurations
- `user_rotations` - User-specific rotation configurations
- `user_autoselects` - User-specific autoselect configurations
- `user_prompts` - User-specific prompt overrides
- `user_auth_files` - User authentication file metadata
- `user_oauth2_credentials` - OAuth2 credentials per user/provider
**Billing & Subscriptions:**
- `account_tiers` - Subscription tier definitions
- `payment_methods` - User payment methods
- `user_subscriptions` - Active subscriptions
- `payment_transactions` - Payment history
**Analytics & Tracking:**
- `context_dimensions` - Context usage tracking
- `token_usage` - Token usage for rate limiting
- `user_token_usage` - User-specific token usage
- `model_embeddings` - Cached model embeddings
### cache.db (Cache Database)
This database contains ONLY temporary caching data:
- `cache` - General purpose cache
- `response_cache` - AI response caching
## Migration Issue
In some installations, configuration tables (especially `users`) were incorrectly created in `cache.db` instead of `aisbf.db`. This causes issues because:
1. Configuration data should persist across cache clears
2. The application expects configuration in `aisbf.db`
3. Cache database should be safe to delete without losing data
## Migration Process
### Step 1: Check Current State
First, verify which database contains your data:
```bash
# Check tables in cache.db
sqlite3 ~/.aisbf/cache.db ".tables"
# Check tables in aisbf.db
sqlite3 ~/.aisbf/aisbf.db ".tables"
```
If you see configuration tables (like `users`, `user_providers`, etc.) in `cache.db`, you need to migrate.
### Step 2: Dry Run
Test the migration without making changes:
```bash
python migrate_cache_to_aisbf.py --dry-run
```
This will show you:
- Which tables will be migrated
- How many rows will be copied
- Any potential issues
### Step 3: Perform Migration
Run the actual migration:
```bash
python migrate_cache_to_aisbf.py
```
The script will:
1. Create backups of both databases
2. Copy configuration tables from `cache.db` to `aisbf.db`
3. Preserve all existing data
4. Show a summary of migrated data
**Backup files are created automatically:**
- `~/.aisbf/cache_backup_YYYYMMDD_HHMMSS.db`
- `~/.aisbf/aisbf_backup_YYYYMMDD_HHMMSS.db`
### Step 4: Verify Migration
After migration, verify the data:
```bash
# Check users table in aisbf.db
sqlite3 ~/.aisbf/aisbf.db "SELECT COUNT(*) FROM users;"
# Check your user exists
sqlite3 ~/.aisbf/aisbf.db "SELECT username, role FROM users;"
```
### Step 5: Test Application
Start AISBF and verify:
1. You can log in with your existing credentials
2. All providers and rotations are available
3. User-specific configurations are preserved
```bash
# Start AISBF
aisbf
# Or if running from source
python main.py
```
### Step 6: Cleanup (Optional)
After confirming everything works, clean up `cache.db`:
```bash
python migrate_cache_to_aisbf.py --cleanup
```
This removes configuration tables from `cache.db`, leaving only cache tables.
## Advanced Options
### Force Overwrite
If destination tables already have data and you want to overwrite:
```bash
python migrate_cache_to_aisbf.py --force
```
### Custom Database Paths
If your databases are in non-standard locations:
```bash
python migrate_cache_to_aisbf.py \
--cache-db /path/to/cache.db \
--aisbf-db /path/to/aisbf.db
```
## Troubleshooting
### Issue: "Table already has rows in destination"
**Solution:** Use `--force` to overwrite, or manually inspect both databases to determine which has the correct data.
### Issue: Migration fails with "database is locked"
**Solution:** Stop AISBF before running migration:
```bash
# Stop AISBF
aisbf stop
# Run migration
python migrate_cache_to_aisbf.py
# Start AISBF
aisbf
```
### Issue: Lost data after migration
**Solution:** Restore from backup:
```bash
# Find your backup
ls -lt ~/.aisbf/*_backup_*.db
# Restore cache.db
cp ~/.aisbf/cache_backup_YYYYMMDD_HHMMSS.db ~/.aisbf/cache.db
# Restore aisbf.db
cp ~/.aisbf/aisbf_backup_YYYYMMDD_HHMMSS.db ~/.aisbf/aisbf.db
```
## Prevention
The code has been updated to ensure proper database separation:
1. **`database.py`** - All methods use `aisbf.db` for configuration
2. **`cache.py`** - All methods use `cache.db` for caching only
3. **Initialization** - Databases are created with correct table separation
After upgrading to the fixed version, new installations will automatically use the correct database structure.
## For Developers
### Database Initialization
```python
from aisbf.database import initialize_database, get_database
# Initialize configuration database (aisbf.db)
initialize_database()
# Get database manager
db = get_database()
# All operations use aisbf.db
user = db.authenticate_user(username, password_hash)
```
### Cache Operations
```python
from aisbf.cache import get_cache_manager
# Initialize cache (cache.db)
cache = get_cache_manager()
# All operations use cache.db
cache.set('key', 'value', ttl=600)
value = cache.get('key')
```
### Adding New Tables
**Configuration tables** (add to `database.py`):
```python
cursor.execute('''
CREATE TABLE IF NOT EXISTS my_config_table (
id INTEGER PRIMARY KEY AUTOINCREMENT,
...
)
''')
```
**Cache tables** (add to `cache.py`):
```python
cursor.execute('''
CREATE TABLE IF NOT EXISTS my_cache_table (
key TEXT PRIMARY KEY,
value TEXT,
ttl REAL
)
''')
```
## Summary
- **aisbf.db** = Configuration & persistent data (users, providers, etc.)
- **cache.db** = Temporary caching only (cache, response_cache)
- **Migration script** = Moves misplaced tables from cache.db to aisbf.db
- **Backups** = Created automatically before any changes
- **Safe** = Can be run multiple times, dry-run available
For questions or issues, refer to the main DOCUMENTATION.md or open an issue on GitHub.
PAYMENT_INSTALLATION.md deleted 100644 → 0
View file @ f182fbd1
# Payment System Installation Guide
The AISBF payment system supports both fiat (Stripe/PayPal) and cryptocurrency payments. Cryptocurrency support is optional due to system dependency requirements.
## Installation Options
### Option 1: Core Payment System Only (Fiat Payments)
Install the base requirements without cryptocurrency support:
```bash
pip install -r requirements.txt
```
This includes:
- ✅ Stripe payment processing
- ✅ PayPal billing agreements
- ✅ Subscription management
- ✅ Email notifications
- ✅ Background scheduler
- ❌ Cryptocurrency payments (BTC, ETH, USDT, USDC)
### Option 2: Full Payment System (Fiat + Crypto)
#### Step 1: Install System Dependencies
**Ubuntu/Debian:**
```bash
sudo apt-get update
sudo apt-get install -y pkg-config libsecp256k1-dev build-essential
```
**RHEL/CentOS/Fedora:**
```bash
sudo yum install -y pkgconfig libsecp256k1-devel gcc
```
**Alpine Linux:**
```bash
sudo apk add pkgconfig libsecp256k1-dev gcc musl-dev
```
#### Step 2: Install Python Dependencies
```bash
pip install -r requirements.txt
pip install -r requirements-crypto.txt
```
This includes:
- ✅ All fiat payment features
- ✅ Cryptocurrency payments (BTC, ETH, USDT, USDC)
- ✅ HD wallet generation (BIP32/BIP44)
- ✅ Blockchain monitoring
- ✅ Multi-exchange price aggregation
## Troubleshooting
### Error: "Could NOT find PkgConfig"
This means system dependencies are missing. Install them using the commands above for your OS.
### Error: "coincurve build failed"
The `coincurve` package requires `libsecp256k1`. Install system dependencies first, then retry.
### Alternative: Use Pre-built Wheels
If you cannot install system dependencies, try using pre-built wheels:
```bash
pip install --only-binary :all: coincurve
pip install -r requirements-crypto.txt
```
## Configuration
After installation, configure the payment system:
1. Set encryption key for HD wallets:
```bash
export ENCRYPTION_KEY="your-fernet-key-here"
```
2. Configure payment gateways in the admin dashboard:
- Stripe API keys
- PayPal client credentials
- Crypto consolidation addresses (if using crypto)
3. Run database migrations:
```bash
python main.py # Migrations run automatically on startup
```
## Features by Installation Type
| Feature | Core Only | Full (Crypto) |
|---------|-----------|---------------|
| Stripe Payments | ✅ | ✅ |
| PayPal Payments | ✅ | ✅ |
| Subscriptions | ✅ | ✅ |
| Auto-renewals | ✅ | ✅ |
| Email Notifications | ✅ | ✅ |
| Quota Enforcement | ✅ | ✅ |
| BTC Payments | ❌ | ✅ |
| ETH/USDT/USDC | ❌ | ✅ |
| HD Wallet | ❌ | ✅ |
| Blockchain Monitor | ❌ | ✅ |
| Wallet Consolidation | ❌ | ✅ |
## Recommendation
For production deployments:
- **With crypto support**: Install on a server where you have root access to install system dependencies
- **Without crypto support**: Use the core installation and rely on Stripe/PayPal for all payments
Both options provide a fully functional subscription payment system.
PAYMENT_INTEGRATION_SUMMARY.md deleted 100644 → 0
View file @ f182fbd1
# Payment Integration Summary
This document summarizes the payment method integrations completed for AISBF.
## Completed Integrations
### 1. Stripe Credit Card Integration ✅
**Status**: Fully functional
**Features**:
- Modal-based card input interface
- Real-time validation with Stripe Elements
- Custom styling to match AISBF theme
- Error handling with inline error display
- Loading states during processing
- Secure token-based payment method storage
**User Flow**:
1. User clicks "Add Credit Card" on billing page
2. Modal opens with Stripe Elements card input
3. User enters card details
4. Stripe validates and creates payment method
5. Payment method ID sent to server
6. Card stored in database with metadata
**Files Modified**:
- `templates/dashboard/add_payment_method.html` - Modal UI and Stripe integration
- `main.py` - `/dashboard/billing/add-method/stripe` endpoint
- `aisbf/database.py` - Payment method storage
### 2. PayPal OAuth Integration ✅
**Status**: Fully functional
**Features**:
- OAuth 2.0 authentication flow
- CSRF protection with state tokens
- Sandbox and production mode support
- Duplicate account detection
- User information storage (email, user ID, name)
- Access token storage for future API calls
**User Flow**:
1. User clicks "Connect PayPal" on billing page
2. Redirected to PayPal OAuth login
3. User authorizes AISBF access
4. PayPal redirects back with authorization code
5. Server exchanges code for access token
6. User info fetched from PayPal API
7. PayPal account stored as payment method
**Endpoints**:
- `GET /dashboard/billing/add-method/paypal/oauth` - Initiates OAuth flow
- `GET /dashboard/billing/add-method/paypal/callback` - Handles OAuth callback
**Files Modified**:
- `main.py` - PayPal OAuth endpoints
- `templates/dashboard/paypal_connect.html` - Error page for configuration issues
- `aisbf/database.py` - Enhanced payment method display logic
- `requirements.txt` - Added paypalrestsdk dependency
**Configuration Required**:
- PayPal Client ID
- PayPal Client Secret
- Sandbox/Production mode toggle
- Callback URL configuration in PayPal app
### 3. Cryptocurrency Payment Methods ✅
**Status**: Functional (default selection)
**Supported Cryptocurrencies**:
- Bitcoin (BTC)
- Ethereum (ETH)
- USDT (Tether)
- USDC (USD Coin)
**User Flow**:
1. User clicks cryptocurrency button
2. System sets as default payment method
3. Crypto type stored in database
**Note**: This is a simplified implementation that sets the preferred crypto type. Actual payment processing would require additional integration with crypto payment gateways.
### 4. User Dashboard Subscription Section ✅
**Status**: Fully functional
**Features**:
- Displays current subscription tier
- Shows plan pricing and limits
- Subscription status and renewal date
- "Add Payment Method" button (only shown when no payment methods exist)
- Links to billing page
**Files Modified**:
- `templates/dashboard/user_index.html` - Added subscription section
- `main.py` - Added subscription context to user dashboard route
## Database Schema
### payment_methods Table
```sql
CREATE TABLE payment_methods (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER NOT NULL,
type VARCHAR(50) NOT NULL, -- 'stripe', 'paypal', 'bitcoin', etc.
identifier VARCHAR(255), -- Email, card last4, or address
is_default BOOLEAN DEFAULT 0,
is_active BOOLEAN DEFAULT 1,
metadata TEXT, -- JSON with additional details
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id)
);
```
### Metadata Examples
**Stripe**:
```json
{
"stripe_payment_method_id": "pm_xxxxx"
}
```
**PayPal**:
```json
{
"paypal_user_id": "USER_ID",
"paypal_email": "user@example.com",
"paypal_name": "John Doe",
"access_token": "ACCESS_TOKEN",
"sandbox": true
}
```
**Cryptocurrency**:
```json
{}
```
## Configuration
### Payment Gateway Settings
Stored in `admin_settings` table with key `payment_gateways`:
```json
{
"stripe": {
"enabled": true,
"publishable_key": "pk_test_xxxxx",
"secret_key": "sk_test_xxxxx",
"webhook_secret": "whsec_xxxxx",
"test_mode": true
},
"paypal": {
"enabled": true,
"client_id": "xxxxx",
"client_secret": "xxxxx",
"webhook_secret": "",
"sandbox": true
},
"bitcoin": {
"enabled": true,
"address": "bc1xxxxx",
"confirmations": 3,
"expiration_minutes": 120
},
"ethereum": {
"enabled": true,
"address": "0xxxxx",
"confirmations": 12,
"chain_id": 1
},
"usdt": {
"enabled": true,
"address": "0xxxxx",
"network": "erc20",
"confirmations": 3
},
"usdc": {
"enabled": true,
"address": "0xxxxx",
"network": "erc20",
"confirmations": 3
}
}
```
## API Endpoints
### Payment Method Management
- `GET /dashboard/billing` - View payment methods and billing history
- `GET /dashboard/billing/add-method` - Add payment method page
- `POST /dashboard/billing/add-method` - Set crypto as default (AJAX)
- `POST /dashboard/billing/add-method/stripe` - Add Stripe card (AJAX)
- `GET /dashboard/billing/add-method/paypal/oauth` - Initiate PayPal OAuth
- `GET /dashboard/billing/add-method/paypal/callback` - PayPal OAuth callback
### Subscription Management
- `GET /dashboard/subscription` - Subscription management page
- `GET /dashboard/pricing` - View available plans
- `GET /dashboard/user` - User dashboard with subscription info
## Security Features
1. **CSRF Protection**: State tokens for OAuth flows
2. **Session Validation**: All endpoints require authentication
3. **HTTPS Required**: PayPal OAuth requires HTTPS in production
4. **Token Storage**: Secure storage of access tokens in database
5. **Duplicate Prevention**: Checks for existing payment methods
6. **Input Validation**: Server-side validation of all inputs
## Testing
### Stripe Testing
Use Stripe test cards:
- Success: `4242 4242 4242 4242`
- Decline: `4000 0000 0000 0002`
- Requires authentication: `4000 0025 0000 3155`
### PayPal Testing
1. Enable sandbox mode in settings
2. Create sandbox accounts at https://developer.paypal.com/dashboard/accounts
3. Use sandbox credentials for testing
### Cryptocurrency Testing
Currently stores preference only. No actual blockchain interaction.
## Future Enhancements
### Stripe
- [ ] Webhook integration for payment events
- [ ] Support for 3D Secure authentication
- [ ] Card update functionality
- [ ] Multiple cards per user
### PayPal
- [ ] Webhook integration for payment notifications
- [ ] Payment processing implementation
- [ ] Subscription creation and management
- [ ] Refund support
- [ ] Token refresh logic
### Cryptocurrency
- [ ] Integration with crypto payment gateways (Coinbase Commerce, BTCPay)
- [ ] QR code generation for payments
- [ ] Payment verification via blockchain
- [ ] Automatic conversion rates
- [ ] Transaction monitoring
### General
- [ ] Payment method editing
- [ ] Payment method deletion with confirmation
- [ ] Set default payment method
- [ ] Payment history with filtering
- [ ] Invoice generation
- [ ] Email notifications for payments
- [ ] Multi-currency support
## Documentation
- `PAYPAL_SETUP.md` - Detailed PayPal configuration guide
- `PAYMENT_INTEGRATION_SUMMARY.md` - This document
- Code comments in relevant files
## Dependencies Added
```
paypalrestsdk # PayPal REST API SDK
```
## Files Modified
1. `main.py` - Payment endpoints and logic
2. `aisbf/database.py` - Payment method storage and retrieval
3. `templates/dashboard/add_payment_method.html` - Payment method UI
4. `templates/dashboard/billing.html` - Billing page
5. `templates/dashboard/user_index.html` - User dashboard
6. `templates/dashboard/paypal_connect.html` - PayPal error page
7. `requirements.txt` - Added PayPal SDK
8. `setup.py` - Added new template files
## Installation
```bash
# Install dependencies
pip install -r requirements.txt
# Or install PayPal SDK separately
pip install paypalrestsdk
```
## Configuration Steps
1. **Configure Stripe** (if using):
- Get API keys from https://dashboard.stripe.com/apikeys
- Add to payment gateway settings
2. **Configure PayPal** (if using):
- Create app at https://developer.paypal.com
- Get Client ID and Secret
- Configure callback URL
- Add to payment gateway settings
3. **Configure Cryptocurrency** (if using):
- Set wallet addresses for each supported currency
- Configure confirmation requirements
4. **Test Integration**:
- Enable test/sandbox modes
- Test each payment method
- Verify database storage
- Check error handling
## Support
For issues or questions:
- Check application logs
- Review payment gateway documentation
- Verify configuration settings
- Test in sandbox/test mode first
## Changelog
### 2026-04-16
- ✅ Implemented Stripe credit card integration with modal UI
- ✅ Implemented PayPal OAuth 2.0 integration
- ✅ Enhanced payment method display logic
- ✅ Added subscription section to user dashboard
- ✅ Created comprehensive documentation
- ✅ Added PayPal SDK dependency
PAYPAL_SETUP.md deleted 100644 → 0
View file @ f182fbd1
# PayPal Payment Integration Setup Guide
This guide explains how to configure PayPal as a payment method in AISBF.
## Overview
AISBF now supports PayPal OAuth integration, allowing users to connect their PayPal accounts as payment methods for subscriptions and plan upgrades.
## Features
- **OAuth 2.0 Integration**: Secure PayPal account connection using OAuth 2.0
- **Automatic Account Detection**: Prevents duplicate PayPal accounts
- **Sandbox Support**: Test mode for development
- **User Information**: Stores PayPal email, user ID, and name
- **Access Token Storage**: Stores access token for future API calls
## Prerequisites
1. **PayPal Developer Account**: Sign up at https://developer.paypal.com
2. **PayPal App Credentials**: Create an app to get Client ID and Secret
## Creating a PayPal App
### Step 1: Create a PayPal Developer Account
1. Go to https://developer.paypal.com
2. Sign in with your PayPal account or create a new one
3. Navigate to "Dashboard"
### Step 2: Create an App
1. Click "Apps & Credentials" in the left sidebar
2. Click "Create App" button
3. Enter an app name (e.g., "AISBF Payment Integration")
4. Select "Merchant" as the app type
5. Click "Create App"
### Step 3: Get Your Credentials
After creating the app, you'll see:
- **Client ID**: Your application's public identifier
- **Secret**: Your application's secret key (click "Show" to reveal)
### Step 4: Configure OAuth Settings
1. Scroll down to "App Settings"
2. Under "Return URL", add your callback URL:
- For production: `https://yourdomain.com/dashboard/billing/add-method/paypal/callback`
- For development: `http://localhost:8000/dashboard/billing/add-method/paypal/callback`
3. Click "Save"
### Step 5: Enable Required Features
1. Under "Features", ensure these are enabled:
- **Log In with PayPal**: Required for OAuth
- **Accept Payments**: Required for payment processing
2. Under "Advanced Features", configure:
- **Return URL**: Your callback URL
- **Privacy Policy URL**: Your privacy policy page
- **User Agreement URL**: Your terms of service page
## Configuring AISBF
### Option 1: Via Dashboard (Recommended)
1. Log in to AISBF dashboard as admin
2. Navigate to "Settings" → "Payment Gateways"
3. Find the "PayPal" section
4. Configure the following:
- **Enabled**: Toggle to enable PayPal
- **Client ID**: Paste your PayPal app Client ID
- **Client Secret**: Paste your PayPal app Secret
- **Sandbox Mode**: Enable for testing, disable for production
- **Webhook Secret**: (Optional) For webhook verification
5. Click "Save Settings"
### Option 2: Via Database
Update the `admin_settings` table:
```sql
INSERT OR REPLACE INTO admin_settings (setting_key, setting_value, updated_at)
VALUES ('payment_gateways', '{
"paypal": {
"enabled": true,
"client_id": "YOUR_CLIENT_ID",
"client_secret": "YOUR_CLIENT_SECRET",
"webhook_secret": "",
"sandbox": true
},
"stripe": {...},
"bitcoin": {...}
}', CURRENT_TIMESTAMP);
```
## Testing the Integration
### Sandbox Testing
1. Enable sandbox mode in PayPal settings
2. Create a sandbox account at https://developer.paypal.com/dashboard/accounts
3. Use sandbox credentials to test the OAuth flow
### Test Flow
1. Navigate to "Billing" → "Add Payment Method"
2. Click "Connect PayPal"
3. You'll be redirected to PayPal login
4. Log in with your PayPal account (or sandbox account)
5. Authorize the connection
6. You'll be redirected back to AISBF
7. PayPal account should appear in your payment methods
## OAuth Flow Details
### Step 1: Initiate OAuth
- User clicks "Connect PayPal" button
- AISBF generates a cryptographically secure state token (64 hex characters)
- State token is stored in user session for CSRF protection
- User is redirected to PayPal OAuth URL with:
- `client_id`: Your PayPal app client ID
- `response_type=code`: Authorization code flow
- `scope=openid profile email`: Requested permissions
- `redirect_uri`: Your callback URL
- `state`: CSRF protection token
### Step 2: User Authorization
- User logs in to PayPal (sandbox or live)
- User reviews requested permissions
- User clicks "Agree and Continue" to authorize
- PayPal redirects back with authorization code and state token
### Step 3: Token Exchange
- AISBF validates state token matches session (CSRF check)
- AISBF exchanges authorization code for access token via PayPal API
- Uses HTTP Basic Auth with base64-encoded client credentials
- Receives access token from PayPal
### Step 4: Fetch User Profile
- AISBF calls PayPal Identity API with access token
- Retrieves user_id, email, and name from PayPal
- Validates required fields are present
### Step 5: Store Payment Method
- AISBF checks for duplicate PayPal accounts (by email and user_id)
- Stores payment method in database with:
- Type: 'paypal'
- Identifier: PayPal email
- Metadata: PayPal user_id, email, name, access token, sandbox flag
- Sets as default if user's first payment method
- Redirects to billing page with success message
## Security Considerations
1. **HTTPS Required**: PayPal OAuth requires HTTPS in production
2. **State Token**: CSRF protection using random state tokens
3. **Client Secret**: Never expose client secret in frontend code
4. **Access Token Storage**: Tokens are stored securely in database
5. **Duplicate Prevention**: System checks for existing PayPal accounts
## Troubleshooting
### Error: "PayPal is not enabled"
- Check that PayPal is enabled in payment gateway settings
- Verify admin_settings table has correct configuration
### Error: "PayPal is not properly configured"
- Ensure Client ID is set in gateway settings
- Verify Client ID is correct
### Error: "Invalid state token"
- This is a CSRF protection error
- Clear browser cookies and try again
- Check that sessions are working properly
### Error: "Failed to connect PayPal account"
- Check that Client Secret is correct
- Verify callback URL is configured in PayPal app settings
- Check server logs for detailed error messages
### Error: "This PayPal account is already connected"
- User already has this PayPal account as a payment method
- Remove existing PayPal method first, then reconnect
## API Endpoints
### Initiate OAuth
```
GET /dashboard/billing/add-method/paypal/oauth
```
Redirects to PayPal OAuth URL
### OAuth Callback
```
GET /dashboard/billing/add-method/paypal/callback?code=xxx&state=xxx
```
Handles OAuth callback and stores payment method
## Database Schema
### payment_methods Table
```sql
CREATE TABLE payment_methods (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER NOT NULL,
type VARCHAR(50) NOT NULL, -- 'paypal'
identifier VARCHAR(255), -- PayPal email
is_default BOOLEAN DEFAULT 0,
is_active BOOLEAN DEFAULT 1,
metadata TEXT, -- JSON with PayPal details
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id)
);
```
### Metadata Structure
```json
{
"paypal_user_id": "PAYPAL_USER_ID",
"paypal_email": "user@example.com",
"paypal_name": "John Doe",
"access_token": "ACCESS_TOKEN",
"sandbox": true
}
```
## Production Checklist
- [ ] Create production PayPal app
- [ ] Configure production callback URL
- [ ] Set sandbox mode to `false`
- [ ] Test OAuth flow in production
- [ ] Verify HTTPS is enabled
- [ ] Configure webhook endpoints (if needed)
- [ ] Test payment processing
- [ ] Monitor error logs
## Future Enhancements
- **Webhook Integration**: Handle PayPal webhooks for payment notifications
- **Payment Processing**: Process actual payments using PayPal API
- **Subscription Management**: Create and manage PayPal subscriptions
- **Refund Support**: Handle refunds through PayPal API
- **Token Refresh**: Implement access token refresh logic
## Support
For issues or questions:
- Check server logs: `/var/log/aisbf/` or application logs
- Review PayPal Developer documentation: https://developer.paypal.com/docs/
- Contact AISBF support
## References
- [PayPal OAuth Documentation](https://developer.paypal.com/docs/log-in-with-paypal/)
- [PayPal REST API](https://developer.paypal.com/docs/api/overview/)
- [PayPal Sandbox Testing](https://developer.paypal.com/docs/api-basics/sandbox/)
PAYPAL_TROUBLESHOOTING.md deleted 100644 → 0
View file @ f182fbd1
# PayPal OAuth Integration Troubleshooting Guide
## Common Error: "invalid client_id or redirect_uri"
This error occurs when PayPal cannot validate your OAuth request. Here's how to fix it.
## Quick Fix Checklist
### 1. Verify PayPal App Configuration
Go to https://developer.paypal.com/dashboard/applications and check:
- [ ] App is created and active
- [ ] You're using the correct Client ID
- [ ] Sandbox mode matches your configuration
- [ ] Return URL is properly configured
### 2. Configure Return URL in PayPal App
**CRITICAL:** The Return URL in PayPal app settings must EXACTLY match your callback URL.
#### Steps:
1. Open your PayPal app in developer dashboard
2. Scroll to **"Return URL"** section
3. Add your callback URL:
```
https://yourdomain.com/dashboard/billing/add-method/paypal/callback
```
4. Click **Save**
#### Important Notes:
- Must use **HTTPS** in production (HTTP only for localhost testing)
- URL is **case-sensitive**
- No trailing slash (unless your logs show one)
- Must match exactly what appears in server logs
### 3. Check Server Logs
The AISBF server logs the redirect_uri being used. Check logs:
```bash
# View logs
tail -f /var/log/aisbf/app.log | grep "PayPal OAuth"
# Or if using systemd
journalctl -u aisbf -f | grep "PayPal OAuth"
```
Look for lines like:
```
PayPal OAuth redirect_uri: https://yourdomain.com/dashboard/billing/add-method/paypal/callback
PayPal OAuth client_id: AYxxxxxx...
PayPal OAuth sandbox mode: True
```
### 4. Verify Configuration in AISBF
Check your PayPal settings in AISBF admin dashboard:
1. Login as admin
2. Go to Settings → Payment Gateways
3. Check PayPal section:
- [ ] Enabled: Yes
- [ ] Client ID: Matches PayPal app
- [ ] Client Secret: Matches PayPal app
- [ ] Sandbox Mode: Matches PayPal app type
## Detailed Troubleshooting
### Issue: Wrong Client ID
**Symptoms:**
- Error: "invalid client_id"
- PayPal rejects immediately
**Solution:**
1. Go to PayPal developer dashboard
2. Open your app
3. Copy the **Client ID** (starts with "A" for live, different for sandbox)
4. Update in AISBF admin settings
5. Make sure you're using:
- **Sandbox Client ID** if sandbox mode is enabled
- **Live Client ID** if sandbox mode is disabled
### Issue: Redirect URI Not Registered
**Symptoms:**
- Error: "invalid redirect_uri"
- PayPal shows "action is not supported"
**Solution:**
1. Check server logs for the exact redirect_uri being used
2. Go to PayPal app settings
3. Add that EXACT URL to "Return URL" field
4. Common mistakes:
- Using http instead of https
- Adding/missing trailing slash
- Wrong domain name
- Typo in path
### Issue: Sandbox vs Production Mismatch
**Symptoms:**
- Works in sandbox but not production (or vice versa)
- Client ID seems correct but still fails
**Solution:**
- Sandbox apps and Live apps are separate in PayPal
- You need TWO apps:
- One for sandbox (for testing)
- One for production (for live)
- Make sure AISBF sandbox mode matches the app type you're using
### Issue: HTTPS vs HTTP
**Symptoms:**
- Logs show http:// but PayPal expects https://
- Works locally but not on server
**Solution:**
If behind a reverse proxy (nginx, Apache):
1. Ensure proxy sets X-Forwarded-Proto header:
```nginx
proxy_set_header X-Forwarded-Proto $scheme;
```
2. AISBF should detect this automatically via ProxyHeadersMiddleware
3. If still using http://, check:
- Proxy configuration
- SSL certificate is valid
- AISBF is receiving correct headers
## Testing Procedure
### 1. Test with Sandbox First
1. Create a sandbox app in PayPal developer dashboard
2. Get sandbox Client ID and Secret
3. Configure AISBF with sandbox credentials
4. Set sandbox mode to `true`
5. Add sandbox return URL
6. Test the OAuth flow
### 2. Verify Each Step
**Step 1: Check Configuration**
```bash
# Check AISBF logs when clicking "Connect PayPal"
tail -f /var/log/aisbf/app.log
```
**Step 2: Verify Redirect**
- Click "Connect PayPal" in AISBF
- Check browser URL bar
- Should redirect to: `https://www.sandbox.paypal.com/signin/authorize?client_id=...`
**Step 3: Check PayPal Response**
- If you see PayPal login page: ✅ OAuth URL is correct
- If you see error page: ❌ Check client_id or redirect_uri
**Step 4: Complete Flow**
- Login with PayPal sandbox account
- Authorize the app
- Should redirect back to AISBF
- Check if PayPal account appears in payment methods
### 3. Move to Production
Once sandbox works:
1. Create a live app in PayPal dashboard
2. Get live Client ID and Secret
3. Update AISBF configuration
4. Set sandbox mode to `false`
5. Add production return URL (must use HTTPS)
6. Test with real PayPal account
## Configuration Examples
### Sandbox Configuration
```json
{
"paypal": {
"enabled": true,
"client_id": "AYSq3RDGsmBLJE-otTkBtM-jBRd1TCQwFf9RGfwddNXWz0uFU9ztymylOhRS",
"client_secret": "EGnHDxD_qRPdaLdZz8iCr8N7_MzF-YHPTkjs6NKYQvQSBngp4PTTVWkPZRbL",
"sandbox": true
}
}
```
Return URL in PayPal sandbox app:
```
https://yourdomain.com/dashboard/billing/add-method/paypal/callback
```
### Production Configuration
```json
{
"paypal": {
"enabled": true,
"client_id": "AeHGtyuJHGFRTYUIKJHGFRTYUIKJHGFRTYUIKJHGFRTYUIKJHGFRTYUIKJH",
"client_secret": "ELkjhgfdsaLKJHGFDSALKJHGFDSALKJHGFDSALKJHGFDSALKJHGFDSALKJ",
"sandbox": false
}
}
```
Return URL in PayPal live app:
```
https://yourdomain.com/dashboard/billing/add-method/paypal/callback
```
## Debug Mode
To see detailed OAuth flow information:
1. Check AISBF logs for PayPal OAuth messages
2. Use browser developer tools (Network tab) to see redirects
3. Check PayPal app dashboard for API call logs
## Still Having Issues?
### Check These:
1. **Client ID Format**
- Sandbox: Usually starts with "AY" or "AS"
- Live: Different format
- Should be 80+ characters long
2. **Return URL Format**
- Must be absolute URL (include https://)
- Must include full path
- No query parameters
- No fragments (#)
3. **PayPal App Status**
- App must be active (not disabled)
- For live apps, may need PayPal approval
4. **Network Issues**
- Firewall blocking PayPal API calls
- DNS resolution issues
- SSL certificate problems
### Get Help
If still stuck:
1. Check server logs for detailed error messages
2. Review PayPal app settings carefully
3. Test with PayPal sandbox first
4. Verify HTTPS is working correctly
5. Check that redirect_uri in logs matches PayPal settings exactly
## Quick Reference
### PayPal OAuth Endpoints
**Sandbox:**
- Authorization: `https://www.sandbox.paypal.com/signin/authorize`
- Token: `https://api.sandbox.paypal.com/v1/oauth2/token`
- User Info: `https://api.sandbox.paypal.com/v1/identity/oauth2/userinfo`
**Production:**
- Authorization: `https://www.paypal.com/signin/authorize`
- Token: `https://api.paypal.com/v1/oauth2/token`
- User Info: `https://api.paypal.com/v1/identity/oauth2/userinfo`
### Required OAuth Parameters
- `client_id`: Your PayPal app Client ID
- `response_type`: `code`
- `scope`: `openid profile email`
- `redirect_uri`: Your callback URL (URL encoded)
- `state`: Random token for CSRF protection
### AISBF Callback URL
Always:
```
https://yourdomain.com/dashboard/billing/add-method/paypal/callback
```
Replace `yourdomain.com` with your actual domain.
## Success Indicators
You'll know it's working when:
1. ✅ Clicking "Connect PayPal" redirects to PayPal login
2. ✅ After login, you see PayPal authorization screen
3. ✅ After authorizing, you're redirected back to AISBF
4. ✅ PayPal account appears in payment methods list
5. ✅ No errors in server logs
## Common Success Path
```
User clicks "Connect PayPal"
↓
AISBF generates state token
↓
AISBF redirects to PayPal with client_id and redirect_uri
↓
User logs into PayPal
↓
User authorizes AISBF
↓
PayPal redirects to callback URL with authorization code
↓
AISBF exchanges code for access token
↓
AISBF fetches user info from PayPal
↓
AISBF stores PayPal account as payment method
↓
User sees PayPal account in payment methods list
```
---
**Last Updated:** 2026-04-16
**Version:** 1.0
**For AISBF:** v0.99.26+
SESSION_SUMMARY.md deleted 100644 → 0
View file @ f182fbd1
# Session Summary - Database & Analytics Fixes
## Issues Resolved
### 1. ✅ Lost Account Tiers After Server Restart
**Problem**: Custom account tiers disappeared after restarting the server, leaving only the default "Free Tier"
**Root Cause**:
- April 14 (commit `f997a0f`): `account_tiers` table creation removed from `database.py`
- April 16 (commit `0052431`): Payment migrations added without `account_tiers` table
- Result: Table existed but migrations didn't recreate it
**Solution**:
- Added `_create_account_tiers_table()` method to payment migrations
- Creates table with all columns including `is_visible`
- Ensures default "Free Tier" exists
- Uses `CREATE TABLE IF NOT EXISTS` to preserve existing data
**Commit**: `11330e9` - fix: add account_tiers and admin_settings tables to payment migrations
---
### 2. ✅ Lost Payment Gateway Configurations (MySQL)
**Problem**: Payment gateway settings (Stripe, PayPal, crypto) disappeared after upgrading to v0.99.29 on MySQL
**Root Cause**:
- Payment gateway settings stored in `admin_settings` table
- Table only created in `database.py` migrations, not in payment migrations
- MySQL installations using payment migrations never created the table
**Solution**:
- Added `admin_settings` table creation to `_create_config_tables()` in payment migrations
- Table stores payment gateway configs, encryption keys, and other admin settings
- Uses `CREATE TABLE IF NOT EXISTS` to preserve existing data
**Commit**: `11330e9` - fix: add account_tiers and admin_settings tables to payment migrations
---
### 3. ✅ Analytics Not Recording ALL Requests
**Problem**: Analytics dashboard showed incomplete data - many requests were missing
**Root Cause**:
Analytics recording was incomplete:
- ❌ Failed rotation requests - NOT recorded
- ❌ Failed autoselect requests - NOT recorded
- ❌ Streaming requests (all types) - NOT recorded
- ❌ Authentication failures - NOT recorded
- ✅ Successful direct provider requests - Recorded
- ✅ Successful rotation requests - Recorded
- ✅ Successful autoselect requests - Recorded
**Solution**:
Added comprehensive analytics recording for ALL request types:
1. **Failed Rotation Requests** (line 2857+)
- Records when all rotation attempts are exhausted
- Tracks error type as 'RotationFailure'
2. **Failed Autoselect Requests** (line 4177+)
- Wraps rotation call in try-catch
- Records analytics on exception before re-raising
3. **Streaming Requests - Success** (line 1200+)
- Calculates tokens from accumulated response text
- Records after successful streaming completion
4. **Streaming Requests - Failure** (line 1225+)
- Estimates tokens for failed request
- Records error type before yielding error
5. **Authentication Failures** (line 366+)
- Records when API key is missing
- Tracks error type as 'AuthenticationError'
**Commit**: `f2fe4c1` - fix: add comprehensive analytics recording for all request types
---
### 4. ✅ Misleading Migration Log Messages
**Problem**: Log message "✅ Default payment system data inserted" appeared on every boot, suggesting data was being re-inserted
**Reality**:
- System uses `INSERT OR IGNORE` (SQLite) / `INSERT IGNORE` (MySQL)
- Only inserts if record doesn't exist (based on UNIQUE constraints)
- Existing records are NEVER overwritten
- User modifications are preserved
**Solution**:
- Changed log message to "✅ Default payment system data checked (existing records preserved)"
- Added comments explaining INSERT OR IGNORE behavior
- Clarifies that the system only inserts missing defaults
**Commit**: `66565a9` - fix: improve migration logging to clarify data preservation
---
## Current Database Status
```
Account Tiers: 1 (default Free Tier)
Admin Settings: 0 (empty, ready for configuration)
Token Usage: 35 requests tracked
Price Sources: 3 (Coinbase, Binance, Kraken)
Email Notifications: 9 notification types configured
```
---
## What Users Need to Do
### For Lost Tiers (All Databases):
1. ✅ Migrations run automatically on server restart
2. ✅ Table structure is verified/created
3. ⚠️ **You must recreate your custom tiers** through the admin dashboard
4. ✅ Future restarts will preserve your tiers
### For Lost Payment Gateway Configs (MySQL Only):
1. ✅ Migrations run automatically on server restart
2. ✅ `admin_settings` table is created
3. ⚠️ **You must reconfigure payment gateways** through Admin → Payment Settings
4. ✅ Future restarts will preserve your settings
### For Analytics:
1. ✅ All request types are now tracked automatically
2. ✅ Dashboard shows complete data
3. ✅ No action required
---
## Technical Details
### Migration Safety
All fixes use `CREATE TABLE IF NOT EXISTS` and `INSERT OR IGNORE`:
- ✅ Existing tables are preserved
- ✅ Existing data is NOT deleted
- ✅ Safe to run on existing installations
- ✅ Safe to run multiple times
- ✅ User modifications are never overwritten
### Token Estimation
For requests without token counts, we estimate:
- Use `count_messages_tokens()` for prompt tokens
- Estimate completion based on `max_tokens` or typical response
- Fallback to 50 tokens minimum for failed requests
### Analytics Recording
Now tracks:
- Provider ID
- Model name
- Tokens used (actual or estimated)
- Latency (when available)
- Success/failure status
- Error type (for failures)
- User ID and token ID (when authenticated)
- Rotation/autoselect ID (when applicable)
---
## Files Modified
1. **aisbf/payments/migrations.py**
- Added `_create_account_tiers_table()` method
- Added `admin_settings` table to `_create_config_tables()`
- Added default tier insertion
- Improved logging messages
2. **aisbf/handlers.py**
- Added analytics for failed rotation requests
- Added analytics for failed autoselect requests
- Added analytics for streaming requests (success/failure)
- Added analytics for authentication failures
- Total: 259 lines added, 32 lines removed
3. **Documentation**
- MIGRATION_FIXES.md - Tier and gateway fixes
- ANALYTICS_FIX.md - Analytics recording fixes
---
## Commits
```
66565a9 fix: improve migration logging to clarify data preservation
c4aa7ff docs: add analytics fix documentation
f2fe4c1 fix: add comprehensive analytics recording for all request types
11330e9 fix: add account_tiers and admin_settings tables to payment migrations
```
---
## Version
These fixes are included in **v0.99.29** and ready for deployment.
---
## Testing Performed
✅ Direct provider requests - Recorded in analytics
✅ Streaming requests - Recorded in analytics
✅ Failed rotation requests - Recorded in analytics
✅ Account tiers table - Created and preserved
✅ Admin settings table - Created and preserved
✅ Default data - Only inserted if missing
✅ User modifications - Preserved across restarts
---
## Impact
- **Complete analytics** - All requests are now tracked
- **Data preservation** - User configurations are never lost
- **Clear logging** - Migration messages accurately reflect behavior
- **Production ready** - Safe to deploy on existing installations
qwen-oauth2-analysis.md deleted 100644 → 0
View file @ f182fbd1
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment