Complete reorganization of project documentation to improve discoverability, navigation, and maintainability. All documentation has been restructured into a clear, role-based hierarchy. ## Major Changes ### New Directory Structure - Created `docs/api/` for API documentation - Created `docs/admin/` with subdirectories: - `admin/configuration/` - Configuration guides - `admin/deployment/` - Deployment guides - `admin/security/` - Security documentation - `admin/monitoring/` - Monitoring and analytics - Created `docs/development/` for developer documentation - Created `docs/guides/` for user-facing guides - Created `docs/reports/` for analysis reports and summaries - Created `docs/changelog/` for detailed changelog entries (ready for future use) ### File Organization #### Moved from Root Directory (40+ files) - Implementation notes → `docs/implementation-notes/` - Test reports → `docs/testing/` - Analysis reports → `docs/reports/` - User guides → `docs/guides/` #### Reorganized within docs/ - API documentation → `docs/api/` - Administrator documentation → `docs/admin/` (with subdirectories) - Developer documentation → `docs/development/` - Security documentation → `docs/admin/security/` - Telemetry documentation → `docs/admin/monitoring/` ### Documentation Updates #### docs/README.md - Complete rewrite with improved navigation - Added visual documentation map - Organized by role (Users, Administrators, Developers) - Better categorization and quick links - Updated all internal links to new structure #### README.md (root) - Updated all documentation links to reflect new structure - Fixed 8 broken links #### app/templates/main/help.html - Enhanced "Where can I get additional help?" section - Added links to new documentation structure - Added documentation index link - Added admin documentation link for administrators - Improved footer with organized documentation links - Added "Complete Documentation" section with role-based links ### New Index Files - Created README.md files for all new directories: - `docs/api/README.md` - `docs/guides/README.md` - `docs/reports/README.md` - `docs/development/README.md` - `docs/admin/README.md` ### Cleanup - Removed empty `docs/security/` directory (moved to `admin/security/`) - Removed empty `docs/telemetry/` directory (moved to `admin/monitoring/`) - Root directory now only contains: README.md, CHANGELOG.md, LICENSE ## Results **Before:** - 45+ markdown files cluttering root directory - Documentation scattered across root and docs/ - Difficult to find relevant documentation - No clear organization structure **After:** - 3 files in root directory (README, CHANGELOG, LICENSE) - Clear directory structure organized by purpose and audience - Easy navigation with role-based organization - All documentation properly categorized - Improved discoverability ## Benefits 1. Better Organization - Documentation grouped by purpose and audience 2. Easier Navigation - Role-based sections (Users, Admins, Developers) 3. Improved Discoverability - Clear structure with README files in each directory 4. Cleaner Root - Only essential files at project root 5. Maintainability - Easier to add and organize new documentation ## Files Changed - 40+ files moved from root to appropriate docs/ subdirectories - 15+ files reorganized within docs/ - 3 major documentation files updated (docs/README.md, README.md, help.html) - 5 new README index files created - 2 empty directories removed All internal links have been updated to reflect the new structure.
7.2 KiB
CSRF Token Troubleshooting Quick Reference
🔴 Problem: Forms fail with "CSRF token missing or invalid"
Quick Checks (30 seconds)
Run this command to diagnose:
# Linux/Mac
bash scripts/verify_csrf_config.sh
# Windows
scripts\verify_csrf_config.bat
Common Causes & Solutions
✅ 1. SECRET_KEY Changed or Not Set
Symptom: All forms suddenly stopped working after restart
Check:
docker-compose exec app env | grep SECRET_KEY
Solution:
# Generate a secure key
python -c "import secrets; print(secrets.token_hex(32))"
# Add to .env file
echo "SECRET_KEY=your-generated-key-here" >> .env
# Restart
docker-compose restart app
Prevention: Store SECRET_KEY in .env file and add to .gitignore
✅ 2. CSRF Protection Disabled
Symptom: No csrf_token field in forms
Check:
docker-compose exec app env | grep WTF_CSRF_ENABLED
Solution:
# In .env file
WTF_CSRF_ENABLED=true
# Restart
docker-compose restart app
✅ 3. Cookies Blocked by Browser
Symptom: Works on one browser but not another
Check:
- Open browser DevTools → Application → Cookies
- Look for
sessioncookie from your domain
Solution:
- Enable cookies in browser settings
- Check if browser extensions are blocking cookies
- Try incognito/private mode to test
✅ 4. Reverse Proxy Issues
Symptom: Works on localhost but fails behind nginx/traefik/apache
Check nginx config:
proxy_pass http://timetracker:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# IMPORTANT: Don't strip cookies!
proxy_pass_request_headers on;
proxy_cookie_path / /;
Solution:
- Ensure proxy forwards cookies
- Check
proxy_cookie_domainandproxy_cookie_path - Verify HOST header is correct
✅ 5. Token Expired
Symptom: Forms work initially, then fail after some time
Check:
docker-compose exec app env | grep WTF_CSRF_TIME_LIMIT
Solution:
# In .env file - increase timeout (in seconds)
WTF_CSRF_TIME_LIMIT=7200 # 2 hours
# Or disable expiration (less secure)
WTF_CSRF_TIME_LIMIT=null
# Restart
docker-compose restart app
✅ 6. Multiple App Instances with Different SECRET_KEYs
Symptom: Intermittent failures, works sometimes but not always
Check:
# Check all containers
docker ps --filter "name=timetracker-app"
# Check each one
docker exec timetracker-app-1 env | grep SECRET_KEY
docker exec timetracker-app-2 env | grep SECRET_KEY
Solution:
- Ensure ALL instances use the SAME SECRET_KEY
- Use Docker secrets or environment files
- Never let each container generate its own key
✅ 7. Clock Skew
Symptom: Tokens expire immediately or at wrong times
Check:
docker exec app date
date
Solution:
# On host, sync time
sudo ntpdate -s time.nist.gov
# Or install NTP daemon
sudo apt-get install ntp
sudo systemctl start ntp
# Restart container
docker-compose restart app
✅ 8. Accessing via IP Address (Not Localhost)
Symptom: Works on localhost but CSRF cookie not created when accessing via IP (e.g., 192.168.1.100)
Cause: WTF_CSRF_SSL_STRICT=true blocks cookies on HTTP connections to non-localhost addresses
Check:
docker-compose exec app env | grep WTF_CSRF_SSL_STRICT
Solution:
# In .env file
WTF_CSRF_SSL_STRICT=false
SESSION_COOKIE_SECURE=false
CSRF_COOKIE_SECURE=false
# Restart
docker-compose restart app
Note: Only use these settings for development/testing on trusted networks. Production should use HTTPS with strict settings.
See: docs/CSRF_IP_ACCESS_GUIDE.md for detailed explanation
✅ 9. Development/Testing: Just Disable CSRF
⚠️ WARNING: Only for local development/testing!
# In .env file
WTF_CSRF_ENABLED=false
# Restart
docker-compose restart app
NEVER do this in production!
🔍 Diagnostic Commands
Check Configuration
# View all CSRF-related env vars
docker-compose exec app env | grep -E "(SECRET_KEY|CSRF|COOKIE)"
# Check app logs for CSRF errors
docker-compose logs app | grep -i csrf
# Test health endpoint
curl -v http://localhost:8080/_health
Check Cookies in Browser
- Open DevTools (F12)
- Go to Application → Cookies
- Look for
sessioncookie - Check it has proper domain and path
- Verify it's not marked as expired
Verify CSRF Token in HTML
- Open any form page
- View page source (Ctrl+U)
- Search for
csrf_token - Should see:
<input type="hidden" name="csrf_token" value="...">
Test with curl
# Get login page and save cookies
curl -c cookies.txt http://localhost:8080/login -o login.html
# Extract CSRF token
TOKEN=$(grep csrf_token login.html | grep -oP 'value="\K[^"]+')
# Try to login with token
curl -b cookies.txt -c cookies.txt \
-d "username=admin" \
-d "csrf_token=$TOKEN" \
http://localhost:8080/login
📋 Checklist: Fresh Deployment
When deploying TimeTracker for the first time:
- Generate secure SECRET_KEY:
python -c "import secrets; print(secrets.token_hex(32))" - Add SECRET_KEY to
.envfile - Verify
WTF_CSRF_ENABLED=truein production - If using HTTPS, set
SESSION_COOKIE_SECURE=true - If behind reverse proxy, configure cookie forwarding
- Start containers:
docker-compose up -d - Run verification:
bash scripts/verify_csrf_config.sh - Test form submission (try logging in)
- Check logs:
docker-compose logs app | grep -i csrf
🆘 Still Not Working?
Enable Debug Logging
# In .env file
LOG_LEVEL=DEBUG
# Restart
docker-compose restart app
# Watch logs
docker-compose logs -f app
Nuclear Option: Fresh Start
# Stop and remove containers
docker-compose down
# Remove volumes (⚠️ this deletes data!)
docker-compose down -v
# Clean rebuild
docker-compose build --no-cache
docker-compose up -d
Get More Help
- Check detailed documentation:
docs/CSRF_CONFIGURATION.md - Review original fix:
CSRF_TOKEN_FIX_SUMMARY.md - Check application logs in
logs/timetracker.log - Search existing issues on GitHub
- Create new issue with:
- Output of
verify_csrf_config.sh - Relevant logs from
docker-compose logs app - Browser console errors (F12 → Console)
- Network tab showing failed requests
- Output of
💡 Pro Tips
- Use
.envfile: Store SECRET_KEY there, never in docker-compose.yml - Version control: Add
.envto.gitignore - Documentation: Keep SECRET_KEY in secure password manager
- Monitoring: Watch for CSRF errors in logs
- Testing: Test after any reverse proxy changes
- Backups: Include SECRET_KEY in backup procedures
🔗 Related Documentation
- Detailed CSRF Configuration Guide
- CSRF IP Access Guide - For localhost vs IP address issues
- Original CSRF Implementation
- Docker Setup Guide
- Troubleshooting Guide
Last Updated: October 2025
Applies To: TimeTracker v1.0+