- Add backend endpoint to fetch ICE server credentials from Cloudflare
- Implement dynamic ICE server configuration in frontend
- Add fallback to public STUN servers when Cloudflare unavailable
- Create comprehensive test suite for WebRTC API endpoint
- Update environment configuration with Cloudflare TURN credentials
Backend changes:
- New route: GET /api/webrtc/ice-servers (authenticated)
- Fetches temporary credentials from Cloudflare API with 24h TTL
- Returns formatted ICE servers for RTCPeerConnection
- Graceful fallback to Google STUN servers on errors
Frontend changes:
- Remove hardcoded ICE servers from useWebRTC hook
- Fetch ICE servers dynamically from backend on mount
- Store servers in ref for peer connection initialization
- Add webrtcAPI service for backend communication
Tests:
- 9 comprehensive tests covering all scenarios
- 100% coverage for webrtc.js route
- Tests authentication, success, and all fallback scenarios
- Add Turnstile widget rendering in RegisterPage on step 2
- Implement programmatic widget initialization with callbacks
- Add token validation before form submission
- Update AuthContext and API service to pass turnstileToken
- Add backend verification via Cloudflare API in register controller
- Include client IP in verification request
- Add validation rule for turnstileToken
- Reset widget on registration error
Database changes:
- Added ContactMessage model to Prisma schema
- Fields: userId, username, firstName, lastName, email, subject, message, status, ipAddress
- Status enum: new, read, resolved
- Relation to User model
Backend changes:
- Added POST /api/public/contact endpoint for form submissions
- Works for both authenticated and non-authenticated users
- Validation for email, subject (3-255 chars), message (10-5000 chars)
- Activity logging for submissions
- Added admin endpoints:
- GET /api/admin/contact-messages - list with filtering by status
- GET /api/admin/contact-messages/:id - view single message (auto-marks as read)
- PATCH /api/admin/contact-messages/:id/status - update status
- DELETE /api/admin/contact-messages/:id - delete message
Frontend changes:
- Created ContactPage at /contact route
- For non-logged-in users: firstName, lastName, email, subject, message fields
- For logged-in users: auto-fills username, shows only email, subject, message
- Character counter for message (max 5000)
- Success screen with auto-redirect to homepage
- Created ContactMessagesPage at /admin/contact-messages
- Two-column layout: message list + detail view
- Filter by status (all, new, read, resolved)
- View message details with sender info and IP address
- Update status and delete messages
- Added admin dropdown menu to Navbar
- Desktop: dropdown with Activity Logs and Contact Messages
- Mobile: expandable submenu
- Click outside to close on desktop
- ChevronDown icon rotates when open
Note: CAPTCHA integration planned for future enhancement
Backend Changes:
- Added public API endpoint /api/public/log-404 (no auth required)
- Created backend/src/routes/public.js for public endpoints
- Added ACTIONS.SYSTEM_404 and CATEGORIES.system to activity log service
- Registered public routes in app.js
Frontend Changes:
- Created NotFoundPage.jsx with standalone layout (no auth required)
- Added publicAPI.log404() to log 404 access attempts
- Logs both authenticated and anonymous users
- Changed profile route from /@:username to /u/:username
- Made profile route public (removed ProtectedRoute wrapper)
- Updated all profile links from /@${username} to /u/${username} in:
- ChatMessage.jsx
- DashboardMatchCard.jsx
- MatchRequestCards.jsx
- MatchCard.jsx
- UserListItem.jsx
- MatchChatPage.jsx
- PublicProfilePage.jsx
Fixes:
- React Router doesn't support @ in path segments
- 404 page now accessible to non-authenticated users without redirect
- Profile route no longer catches all unmatched routes
- Fixed issue where empty string success filter was interpreted as false
- Backend was filtering for only failed logs when success='' was sent
- Added check to skip sending success parameter when empty string
- Activity logs page now shows all logs when filters are set to 'All'
Bug: When user selected 'All' for success filter, frontend sent success='',
backend parsed this as success=false, showing only failed logs (usually none).
Complete implementation of admin activity logs dashboard with real-time
streaming capabilities. Admin users can now monitor all system activity
through a comprehensive web interface.
Features:
- Stats dashboard with 4 key metrics (total logs, unique users, failures, 24h activity)
- Category breakdown visualization with color-coded badges
- Advanced filtering (date range, category, action type, username, success/failure)
- Paginated log table (50 entries per page) with sort by timestamp
- Real-time streaming toggle using Socket.IO
- Color-coded action badges (blue=auth, green=event, purple=match, red=admin, yellow=chat)
- Admin-only access with automatic redirect for non-admin users
- Responsive design for mobile and desktop
Frontend Changes:
- Created ActivityLogsPage.jsx (600+ lines) with complete UI implementation
- Added 3 admin API methods to api.js (getActivityLogs, getActivityLogActions, getActivityLogStats)
- Added /admin/activity-logs route to App.jsx
- Added admin navigation link to Navbar (desktop & mobile) with Shield icon
- Only visible to users with isAdmin flag
Implementation Details:
- Uses getSocket() from socket service for real-time updates
- Joins 'admin_activity_logs' Socket.IO room on streaming enable
- Receives 'activity_log_entry' events and prepends to table (first page only)
- Comprehensive error handling and loading states
- Empty states for no data
- Clean disconnect handling when streaming disabled
Testing:
- Build successful (no errors)
- Ready for manual testing and verification
Phase 8 (Testing) remains for manual verification of all features.
- Extend saveMatchingResults(eventId, suggestions, runId) and set originRunId
- Scheduler/Admin run-now: always pass runId
- Admin API: GET /api/admin/events/:slug/matching-runs/:runId/suggestions
- Prisma: add compound index on (origin_run_id, status)
- Frontend: add getRunSuggestions, expand row in MatchingRunsSection with 'Pairs created in this run' wording
- New adminAPI for run-now and runs listing
- MatchingRunsSection with refresh and run controls
- Integrate into EventDetailsPage under matching configuration
Allow event organizers to configure which divisions run in parallel
(same time slot) for accurate collision detection in the auto-matching
algorithm. Divisions in the same slot will collide with each other.
- Add scheduleConfig JSON field to Event model
- Add PUT /events/:slug/schedule-config API endpoint
- Update matching algorithm to use slot-based collision detection
- Add UI in EventDetailsPage for managing division slots
- Add unit tests for schedule-based collision detection
Add frontend components for auto-matching recording partners:
- RecordingTab component with suggestions list and opt-out toggle
- Tab navigation in EventChatPage (Chat, Uczestnicy, Nagrywanie)
- Matching configuration in EventDetailsPage (deadline, run matching)
- matchingAPI functions in api.js
- Return registrationDeadline and matchingRunAt in GET /events/:slug/details
UI allows users to:
- View who will record their heats
- View heats they need to record
- Accept/reject suggestions
- Opt-out from being a recorder
- Set registration deadline (admin)
- Manually trigger matching (admin)
Allow participants to set their bib/competitor number per event.
Display as badge next to username in participant lists.
- Add competitorNumber field to EventParticipant model
- Add PUT /events/:slug/competitor-number endpoint
- Include competitorNumber in heats/me and heats/all responses
- Add input field in HeatsBanner component
- Display badge in UserListItem component
- Add unit tests for competitor number feature
- Create DashboardPage with active events, matches, and requests
- Add dashboardAPI.getData() to services/api.js
- Add /dashboard route as default landing after login
- Update Navbar with Dashboard and Events links
- Show video exchange and rating status for matches
- Handle match accept/reject/cancel actions
- Change API_URL from hardcoded 'http://localhost:8080/api' to '/api'
- Change SOCKET_URL from hardcoded to window.location.origin
- Fixes production build connecting to wrong port
- Now works correctly in both dev (localhost:8080) and prod (localhost)
Implemented complete WebRTC peer-to-peer file transfer system for match chat:
**Core WebRTC Implementation:**
- Created useWebRTC hook with RTCPeerConnection and RTCDataChannel
- P2P file transfer with 16KB chunking for large files (tested up to 700MB)
- Real-time progress monitoring for sender and receiver
- Automatic file download on receiver side
- End-to-end encryption via DTLS (native WebRTC)
- ICE candidate exchange via Socket.IO signaling
- Support for host candidates (localhost testing)
**WebRTC Detection & User Experience:**
- Automatic WebRTC capability detection on page load
- Detects if ICE candidates can be generated (fails in Opera, privacy-focused browsers, VPNs)
- User-friendly warning component with fix suggestions
- Graceful degradation: disables WebRTC button when blocked
- Suggests alternative methods (video links via Google Drive/Dropbox)
**Socket.IO Improvements:**
- Fixed multiple socket instance creation issue
- Implemented socket instance reuse pattern
- Disabled React.StrictMode to prevent reconnection loops in development
**Technical Details:**
- RTCPeerConnection with configurable STUN servers (currently using localhost config)
- RTCDataChannel with ordered delivery
- Comprehensive logging for debugging (ICE gathering, connection states, signaling)
- Match room-based signaling relay via Socket.IO
- Authorization checks for all WebRTC signaling events
**Files Changed:**
- frontend/src/hooks/useWebRTC.js - Complete WebRTC implementation
- frontend/src/utils/webrtcDetection.js - WebRTC capability detection
- frontend/src/components/WebRTCWarning.jsx - User warning component
- frontend/src/pages/MatchChatPage.jsx - WebRTC integration
- frontend/src/services/socket.js - Socket instance reuse
- frontend/src/main.jsx - Disabled StrictMode for Socket.IO stability
**Testing:**
- ✅ Verified working in Chrome (ICE candidates generated)
- ✅ Tested with 700MB file transfer
- ✅ Detection working in Opera (shows warning when WebRTC blocked)
- ✅ P2P connection establishment and DataChannel opening
- ✅ File chunking and progress monitoring
**TODO:**
- Add STUN server configuration for production (NAT traversal)
- Consider server-based upload fallback for blocked users
Complete the match lifecycle with partner rating functionality.
Backend changes:
- Add POST /api/matches/:slug/ratings endpoint to create ratings
* Validate score range (1-5)
* Prevent duplicate ratings (unique constraint per match+rater+rated)
* Auto-complete match when both users have rated
* Return detailed rating data with user and event info
- Add GET /api/users/:username/ratings endpoint to fetch user ratings
* Calculate and return average rating
* Include rater details and event context for each rating
* Limit to last 50 ratings
- Add hasRated field to GET /api/matches/:slug response
* Check if current user has already rated the match
* Enable frontend to prevent duplicate rating attempts
Frontend changes:
- Update RatePartnerPage to use real API instead of mocks
* Load match data and partner info
* Submit ratings with score, comment, and wouldCollaborateAgain
* Check hasRated flag and redirect if already rated
* Validate match status before allowing rating
* Show loading state and proper error handling
- Update MatchChatPage to show rating status
* Replace "Rate Partner" button with "✓ Rated" badge when user has rated
* Improve button text from "End & rate" to "Rate Partner"
- Add ratings API functions
* matchesAPI.createRating(slug, ratingData)
* ratingsAPI.getUserRatings(username)
User flow:
1. After match is accepted, users can rate each other
2. Click "Rate Partner" in chat to navigate to rating page
3. Submit 1-5 star rating with optional comment
4. Rating saved and user redirected to matches list
5. Chat shows "✓ Rated" badge instead of rating button
6. Match marked as 'completed' when both users have rated
7. Users cannot rate the same match twice
Security improvements:
- Add random CUID slugs to Match model to prevent ID enumeration attacks
- Update all match URLs from /matches/:id to /matches/:slug
- Keep numeric IDs for internal Socket.IO operations only
Backend changes:
- Add slug field to matches table with unique index
- Update all match endpoints to use slug-based lookups (GET, PUT, DELETE)
- Add GET /api/matches/:slug/messages endpoint to fetch message history
- Include matchSlug in all Socket.IO notifications
Frontend changes:
- Update all match routes to use slug parameter
- Update MatchesPage to use slug for accept/reject/navigate operations
- Update MatchChatPage to fetch match data by slug and load message history
- Update RatePartnerPage to use slug parameter
- Add matchesAPI.getMatchMessages() function
Bug fixes:
- Fix MatchChatPage not loading message history from database on mount
- Messages now persist and display correctly when users reconnect
Backend changes:
- Add matches API routes (POST, GET, PUT, DELETE)
- Create/accept/reject match requests
- Auto-create private chat rooms on match acceptance
- Socket.IO notifications for match events (received, accepted, cancelled)
- Users join personal rooms (user_{id}) for notifications
Frontend changes:
- Add MatchesPage component with inbox UI
- Matches navigation link with notification badge
- Real-time match request count updates
- Accept/reject match functionality
- Filter matches by status (all/pending/accepted)
- Integrate match requests in EventChatPage (UserPlus button)
Features:
- Send match requests to event participants
- Accept incoming match requests
- Real-time notifications via Socket.IO
- Automatic private chat room creation
- Match status tracking (pending/accepted/completed)
- Authorization checks (only participants can match)
- Duplicate match prevention
Backend:
- Add event_checkin_tokens table with unique tokens per event
- Implement GET /api/events/:slug/details endpoint (on-demand token generation)
- Implement POST /api/events/checkin/:token endpoint (date validation only in production)
- Implement DELETE /api/events/:slug/leave endpoint
- Add comprehensive test suite for check-in endpoints
Frontend:
- Add EventDetailsPage with QR code display, participant list, and stats
- Add EventCheckinPage with success/error screens
- Add "Leave Event" button with confirmation modal to EventChatPage
- Install qrcode.react library for QR code generation
- Update routing and API client with new endpoints
Features:
- QR codes valid from (startDate-1d) to (endDate+1d)
- Development mode bypasses date validation for testing
- Automatic participant count tracking
- Duplicate check-in prevention
- Token reuse for same event (generated once, cached)
Replace sequential event IDs in URLs with unique alphanumeric slugs to prevent enumeration attacks. Event URLs now use format /events/{slug}/chat instead of /events/{id}/chat.
Backend changes:
- Add slug field (VARCHAR 50, unique) to Event model
- Create migration with auto-generated 12-char MD5-based slugs for existing events
- Update GET /api/events/:slug endpoint (changed from :id)
- Update GET /api/events/:slug/messages endpoint (changed from :eventId)
- Modify Socket.IO join_event_room to accept slug parameter
- Update send_event_message to use stored event context instead of passing eventId
Frontend changes:
- Update eventsAPI.getBySlug() method (changed from getById)
- Update eventsAPI.getMessages() to use slug parameter
- Change route from /events/:eventId/chat to /events/:slug/chat
- Update EventsPage to navigate using event.slug
- Update EventChatPage to fetch event data via slug and use slug in socket events
Security impact: Prevents attackers from discovering all events by iterating sequential IDs.
- Add GET /api/users/:username endpoint for public profiles
- Create PublicProfilePage component with user stats and info
- Add getUserByUsername function to API service
- Add /:username route to App.jsx
- Display user info: name, location, stats, WSDC ID, social links
- Only show public data (no email or sensitive information)
- Accessible only to authenticated users
Users can now view public profiles of other users by visiting
/<username>. The profile displays stats, location, WSDC ID, and
social media links.
Backend changes:
- Add PATCH /api/users/me endpoint for profile updates (firstName, lastName, email)
- Add PATCH /api/users/me/password endpoint for password change
- Email change triggers re-verification flow (emailVerified=false, new verification token/code)
- Send verification email automatically on email change
- Return new JWT token when email changes (to update emailVerified status)
- Add validation for profile update and password change
- Create user controller with updateProfile and changePassword functions
Frontend changes:
- Add ProfilePage with tabbed interface (Profile & Password tabs)
- Profile tab: Edit firstName, lastName, email
- Password tab: Change password (requires current password)
- Add Profile link to navigation bar
- Add authAPI.updateProfile() and authAPI.changePassword() functions
- Update AuthContext user data when profile is updated
- Display success/error messages for profile and password updates
Security:
- Username cannot be changed (permanent identifier)
- Email uniqueness validation
- Password change requires current password
- Email change forces re-verification to prevent hijacking
User flow:
1. User edits profile and changes email
2. Backend sets emailVerified=false and generates new verification tokens
3. Verification email sent to new address
4. User must verify new email to access all features
5. Banner appears until email is verified
Backend changes:
- Socket.IO: Send last 20 messages on join_event_room
- REST API: Add GET /api/events/:eventId/messages endpoint with pagination
- Support for 'before' cursor-based pagination for loading older messages
Frontend changes:
- Load initial 20 messages when joining event chat
- Implement infinite scroll to load older messages on scroll to top
- Add loading indicator for older messages
- Preserve scroll position when loading older messages
- Add eventsAPI.getMessages() function for pagination
User experience:
- New users see last 20 messages immediately
- Scrolling up automatically loads older messages in batches of 20
- Smooth scrolling experience with position restoration
Note: Messages are encrypted in transit via HTTPS/WSS but stored
as plain text in database (no E2E encryption).
Enhanced the fetchAPI function to better handle cases when the server
returns HTML instead of JSON (e.g., when backend is down and nginx
returns 502 Bad Gateway). This prevents confusing error messages like
"Unexpected token '<'" and provides clearer feedback to users.
Changes:
- Check Content-Type header before parsing JSON
- Catch SyntaxError from JSON parsing attempts
- Provide user-friendly error messages for server issues
This fixes the issue where entering WSDC ID 26111 during registration
showed a JSON parsing error when the backend wasn't running.
Backend features:
- AWS SES email service with HTML templates
- Email verification with dual method (link + 6-digit PIN code)
- Password reset workflow with secure tokens
- WSDC API proxy for dancer lookup and auto-fill registration
- Extended User model with verification and WSDC fields
- Email verification middleware for protected routes
Frontend features:
- Two-step registration with WSDC ID lookup
- Password strength indicator component
- Email verification page with code input
- Password reset flow (request + reset pages)
- Verification banner for unverified users
- Updated authentication context and API service
Testing:
- 65 unit tests with 100% coverage of new features
- Tests for auth utils, email service, WSDC controller, and middleware
- Integration tests for full authentication flows
- Comprehensive mocking of AWS SES and external APIs
Database:
- Migration: add WSDC fields (firstName, lastName, wsdcId)
- Migration: add email verification fields (token, code, expiry)
- Migration: add password reset fields (token, expiry)
Documentation:
- Complete Phase 1.5 documentation
- Test suite documentation and best practices
- Updated session context with new features
Implemented WebSocket-based real-time messaging for both event rooms and private match chats using Socket.IO with comprehensive test coverage.
Backend changes:
- Installed socket.io@4.8.1 for WebSocket server
- Created Socket.IO server with JWT authentication middleware
- Implemented event room management (join/leave/messages)
- Added active users tracking with real-time updates
- Implemented private match room messaging
- Integrated Socket.IO with Express HTTP server
- Messages are persisted to PostgreSQL via Prisma
- Added 12 comprehensive unit tests (89.13% coverage)
Frontend changes:
- Installed socket.io-client for WebSocket connections
- Created socket service layer for connection management
- Updated EventChatPage with real-time messaging
- Updated MatchChatPage with real-time private chat
- Added connection status indicators (● Connected/Disconnected)
- Disabled message input when not connected
Infrastructure:
- Updated nginx config to proxy WebSocket connections at /socket.io
- Added Upgrade and Connection headers for WebSocket support
- Set long timeouts (7d) for persistent WebSocket connections
Key features:
- JWT-authenticated socket connections
- Room-based architecture for events and matches
- Real-time message broadcasting
- Active users list with automatic updates
- Automatic cleanup on disconnect
- Message persistence in database
Test coverage:
- 12 tests passing (authentication, event rooms, match rooms, disconnect, errors)
- Socket.IO module: 89.13% statements, 81.81% branches, 91.66% functions
- Overall coverage: 81.19%
Phase 1, Step 4 completed. Ready for Phase 2 (Core Features).
