- Added link to /dashboard/cache-settings in account menu
- Users can now access prompt cache settings from the dashboard
- Located between API Tokens and Subscription

- Check if timestamp is string before calling fromisoformat()
- MySQL returns datetime objects directly, SQLite returns strings
- Fixes login error: 'fromisoformat: argument must be str'

- Check user cache settings before enabling prompt caching
- Same pattern as implemented for Claude provider
- Users can disable cache per provider/model
- Fixes issue where other providers didn't respect user cache settings

- Rename from /dashboard/user/cache-settings to /dashboard/cache-settings
- Rename template from user_cache_settings.html to cache_settings.html
- Follows same pattern as other dashboard pages (tokens, rotations, autoselects)
- Still uses logged in user session to determine which user to serve

- Use self.user_id and self.provider_id instead of request object
- Fixes the 'name 'request' is not defined' error in Claude provider
- Cache settings are now properly checked for each user request

- Add user_cache_settings database table
- Add database methods to get/set cache settings
- Add API endpoints for cache management
- Add /dashboard/user/cache-settings page
- Integrate with Claude provider to respect user cache settings
- Allow disabling cache per provider, per model, or globally

- Previous fix had wrong indentation, code was still outside with block
- Now all cursor.execute() and conn.commit() are properly inside context manager
- This will actually fix the 'Cursor is not connected' error

- Move all cursor operations inside the 'with' context manager block
- Connection was being closed before cursor.execute() was called
- Fixes 'Cursor is not connected' error in token usage recording

- Convert datetime objects to ISO format strings before JSON serialization
- Handles both created_at and updated_at datetime fields
- Fixes TypeError when loading /dashboard/providers for database users

- Convert datetime objects to ISO format strings before passing to template
- Fixes TypeError: Object of type datetime is not JSON serializable
- Handles both created_at and last_used datetime fields

- Move analytics initialization to AFTER database config is loaded
- Prevents DatabaseRegistry from creating SQLite singleton before MySQL config is available
- Fixes issue where db was initialized twice (first with defaults, then with config)

- Log database config from aisbf.json at startup
- Convert Pydantic models to dict before passing to DatabaseRegistry
- Fix MySQL password validation (allow empty passwords)
- Add traceback on database init errors

- Log database type and query being executed
- Log settings being saved (first 200 chars)
- Verify save by reading back from database
- Add traceback on errors
- Will help diagnose why settings aren't persisting

- Fix sandbox checkbox loading logic (use === true instead of !== false)
- Add console logging to debug save operations
- Add auto-reload after save to verify changes
- Fixes issue where sandbox mode always saved as true

- PayPalPaymentHandler now reads from admin_settings via get_payment_gateway_settings()
- StripePaymentHandler now reads from admin_settings via get_payment_gateway_settings()
- Remove references to non-existent payment_gateway_config table
- Fixes 'base_url' attribute error in PayPal handler
- All payment gateway configs now stored in database only

- Replace OpenID OAuth2 flow with Billing Agreement API
- Add missing wrapper methods in payment service
- Remove dead old OAuth code
- Fixes 'invalid client_id or redirect_uri' error

The contact form and Tor status endpoints were trying to import get_config()
from aisbf.config, but this function didn't exist. Add it as a simple wrapper
that returns the already initialized global config instance.

Fixes the error: cannot import name 'get_config' from 'aisbf.config'

The middleware logic is correct and matches requirements:
- Global tokens (aisbf.json): ONLY access global endpoints
- User tokens (database): ONLY access their own /api/u/<username> endpoints
- Database admin users: same as normal users (no special API access)

The old middleware at line 1525 was running before the new one and blocking
requests without proper debug logging. Now only the new middleware with
enhanced logging and error messages will run.

Log token prefix, user_id, authenticated username, and target username
to diagnose username mismatch issues

Shows authenticated_username vs requested_username in error response
to help diagnose username mismatch issues

Added proper authentication check:
- User tokens now correctly give access to their own /api/u/<username> endpoints
- Better error messages distinguish between missing auth and wrong user
- Global tokens still blocked from user endpoints
- User tokens still blocked from global endpoints

Now:
- Global tokens (aisbf.json) ONLY access global endpoints
- User tokens (database) ONLY access their own /api/u/<username> endpoints
- No cross-access possible
- Admin users still have full access

Add separate api_token_access_control_middleware that runs AFTER auth_middleware
so request.state.is_global_token is already set when checking permissions.

Final middleware execution order (FIRST to LAST on request):
1. ProxyHeadersMiddleware
2. SessionMiddleware
3. CORSMiddleware
4. tier_limit_middleware
5. api_token_access_control_middleware (NEW) - blocks global tokens from user endpoints
6. auth_middleware - sets is_global_token flag
7. dashboard_context_middleware - sets is_aisbf_cloud and welcome_shown

✅ Token security: Global tokens CANNOT access /api/u/* user endpoints
✅ Dashboard: Welcome modal and footer links work correctly
✅ Boot flow: Models load from providers.json on startup

Using app.add_middleware() with async function directly broke the startup flow.
Reverted to using @app.middleware("http") decorator which properly wraps
the async function as BaseHTTPMiddleware.

Dashboard context middleware now runs LAST in the decorator registration order,
which means it executes FIRST on requests, after SessionMiddleware.

Boot flow works correctly again: providers are loaded, models are retrieved from providers.json

Middleware execution order was wrong - dashboard context middleware was running
BEFORE SessionMiddleware, so request.session didn't exist yet.

Fixed execution order:
1. ProxyHeadersMiddleware
2. SessionMiddleware
3. CORSMiddleware
4. tier_limit_middleware
5. auth_middleware
6. dashboard_context_middleware

- Add is_aisbf_cloud to login, signup, forgot-password, reset-password pages
- Footer links now appear on all pages (public and authenticated)
- Welcome modal only appears on dashboard homepage after login

Check if modal elements exist before adding event listeners to prevent
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')

- Welcome modal now appears correctly after login (only once per session)
- Footer links (privacy, terms, contact) appear on ALL dashboard pages
- Works for both aisbf.cloud and Tor onion service
- Fixes session flag handling so modal only gets marked seen when user actually closes it

- Add warn parameter to Config.get_provider to suppress warnings when needed
- Update analytics._get_provider_pricing to use warn=False
- Update analytics.get_model_performance to use warn=False

When visiting the analytics page, no WARNING logs are generated anymore
for user-specific providers that exist in the database but not in the
global configuration.