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.
4.9 KiB
CSRF Cookie Fix for Remote IP Access
Problem Summary
✅ Works: Accessing via http://localhost:8080 - CSRF cookies created correctly
❌ Fails: Accessing via http://192.168.1.100:8080 - CSRF cookies NOT created
Root Cause
The WTF_CSRF_SSL_STRICT=true setting (default) blocks cookie creation for HTTP connections to non-localhost addresses. This is a security feature that prevents CSRF tokens from being sent over insecure connections.
Quick Fix
Option 1: Automated Script (Recommended)
Linux/Mac:
bash scripts/fix_csrf_ip_access.sh
Windows:
scripts\fix_csrf_ip_access.bat
The script will:
- Update your
.envfile with correct settings - Restart the application
- Verify the configuration
Option 2: Manual Configuration
Edit your .env file and add/update:
WTF_CSRF_SSL_STRICT=false
SESSION_COOKIE_SECURE=false
CSRF_COOKIE_SECURE=false
Then restart:
docker-compose restart app
What These Settings Do
| Setting | Value | Purpose |
|---|---|---|
WTF_CSRF_SSL_STRICT |
false |
Allows CSRF tokens over HTTP (needed for IP access) |
SESSION_COOKIE_SECURE |
false |
Allows session cookies over HTTP |
CSRF_COOKIE_SECURE |
false |
Allows CSRF cookies over HTTP |
Verification
1. Check Environment Variables
docker-compose exec app env | grep -E "(WTF_CSRF|SESSION_COOKIE|CSRF_COOKIE)"
Expected output:
WTF_CSRF_SSL_STRICT=false
SESSION_COOKIE_SECURE=false
CSRF_COOKIE_SECURE=false
2. Test Cookie Creation
- Open your browser
- Navigate to
http://YOUR_IP:8080 - Open DevTools (F12)
- Go to Application → Cookies
- Verify these cookies exist:
session- Your session cookieXSRF-TOKEN- The CSRF token
3. Test CSRF Endpoint
# Via localhost (should work)
curl -v http://localhost:8080/auth/csrf-token
# Via IP (should now also work)
curl -v http://192.168.1.100:8080/auth/csrf-token
Look for Set-Cookie headers in both responses.
Security Considerations
⚠️ Important Security Notes
These settings are suitable for:
- ✅ Development environments
- ✅ Testing on local networks
- ✅ Private/trusted networks (VPN, home network)
NOT suitable for:
- ❌ Public internet access without HTTPS
- ❌ Production environments with sensitive data
- ❌ Untrusted networks
Production Configuration
For production deployments, always use HTTPS and set:
WTF_CSRF_SSL_STRICT=true
SESSION_COOKIE_SECURE=true
CSRF_COOKIE_SECURE=true
Alternative Solutions
Solution 1: Use a Domain Name
Add to your hosts file instead of using IP:
Linux/Mac (/etc/hosts):
192.168.1.100 timetracker.local
Windows (C:\Windows\System32\drivers\etc\hosts):
192.168.1.100 timetracker.local
Then access via: http://timetracker.local:8080
Solution 2: Set Up HTTPS
For production-like testing with HTTPS:
- Generate self-signed certificate:
openssl req -x509 -newkey rsa:4096 -nodes \
-keyout key.pem -out cert.pem -days 365 \
-subj "/CN=192.168.1.100"
- Update docker-compose to use HTTPS
- Set all security flags to
true
Troubleshooting
Still not working?
-
Verify settings are loaded:
docker-compose exec app env | grep WTF_CSRF_SSL_STRICT -
Check logs:
docker-compose logs app | grep -i csrf -
Try a fresh restart:
docker-compose down docker-compose up -d -
Clear browser cookies:
- DevTools → Application → Cookies → Delete all for this site
-
Test in incognito/private window:
- Rules out browser extension issues
Different browsers behave differently?
- Chrome/Edge: Usually most permissive
- Firefox: Stricter cookie policies
- Safari: Strictest, especially with tracking prevention
Try disabling enhanced tracking protection or privacy features temporarily for testing.
Related Documentation
- Detailed Guide: docs/CSRF_IP_ACCESS_GUIDE.md
- General CSRF Troubleshooting: CSRF_TROUBLESHOOTING.md
- CSRF Configuration: docs/CSRF_CONFIGURATION.md
Summary
The Fix: Set WTF_CSRF_SSL_STRICT=false for HTTP access via IP addresses.
Why It Works: This allows Flask-WTF to create and validate CSRF cookies over HTTP connections to non-localhost addresses.
When to Use: Development, testing, and trusted private networks only. Always use HTTPS with strict settings in production.
Quick Command Reference:
# Apply fix (automated)
bash scripts/fix_csrf_ip_access.sh
# Verify configuration
docker-compose exec app env | grep -E "WTF_CSRF|SESSION_COOKIE|CSRF_COOKIE"
# Restart application
docker-compose restart app
# Check logs
docker-compose logs app | tail -50
Last Updated: October 2024
Applies To: TimeTracker v1.0+