Major improvements applying DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid):
BACKEND CHANGES:
- Fixed public key storage: Store as base64-encoded bytes in LargeBinary column (not double-encoding)
- ElGamal key generation now produces proper "p:g:h" format with colons
- Removed all double base64-encoding issues
- Simplified API responses to decode bytes to UTF-8 strings for JSON serialization
FRONTEND CHANGES:
- Refactored ElGamalEncryption.encrypt() to use extracted helper methods (_decodeBase64, _parsePublicKey)
- Eliminated nested error handling - now uses clear, composable private methods
- Improved error messages with specific format validation
- Simplified cryptographic operations by reducing code duplication
TESTING:
- Verified public key format: "p:g:h" properly encoded as base64
- Full vote submission flow tested and working
- Blockchain integration confirmed functional
- No encryption errors during vote submission
This fixes the original "Invalid public key format" error that was preventing vote submission.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Fix ElGamalEncryption to generate keypair on initialization and provide public_key_bytes property with proper "p:g:h" UTF-8 format
- Add ElGamal alias for backward compatibility with imports
- Improve frontend error handling with detailed base64 decode error messages
- Update .gitignore to specifically ignore backend/lib/ and backend/lib64/ instead of all lib directories, preserving frontend node_modules-style lib/
This fixes the "Invalid public key format" error that was preventing vote submission during testing.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit fixes 5 critical bugs found during code review:
Bug #1 (CRITICAL): Missing API endpoints for election filtering
- Added GET /api/elections/upcoming endpoint
- Added GET /api/elections/completed endpoint
- Both properly filter elections by date
Bug #2 (HIGH): Auth context has_voted state inconsistency
- Backend schemas now include has_voted in LoginResponse and RegisterResponse
- Auth routes return actual has_voted value from database
- Frontend context uses server response instead of hardcoding false
- Frontend API client properly typed with has_voted field
Bug #3 (HIGH): Transaction safety in vote submission
- Simplified error handling in vote submission endpoints
- Now only calls mark_as_voted() once at the end
- Vote response includes voter_marked_voted flag to indicate success
- Ensures consistency even if blockchain submission fails
Bug #4 (MEDIUM): Vote status endpoint
- Verified endpoint already exists at GET /api/votes/status
- Tests confirm proper functionality
Bug #5 (MEDIUM): Response format inconsistency
- Previously fixed in commit e10a882
- Frontend now handles both array and wrapped object formats
Added comprehensive test coverage:
- 20+ backend API tests (tests/test_api_fixes.py)
- 6+ auth context tests (frontend/__tests__/auth-context.test.tsx)
- 8+ elections API tests (frontend/__tests__/elections-api.test.ts)
- 10+ vote submission tests (frontend/__tests__/vote-submission.test.ts)
All fixes ensure frontend and backend communicate consistently.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Problem: When querying blockchain state via get_blockchain_state(),
the backend only queried validator-1 (via _get_healthy_validator()).
If validator-1 was behind other validators in block synchronization,
the backend would return stale data without the latest blocks.
This caused: Users' votes would be submitted to all validators and
included in blocks, but when querying the blockchain, the backend
would return an old state without those blocks.
Root cause: No block synchronization between validators yet. When a
validator creates a block, it doesn't immediately get to all peers.
So different validators can have different chain lengths.
Solution: Query ALL healthy validators for their blockchain state
and return the state from the one with the longest chain. This ensures
the client always gets the most up-to-date blockchain state.
Implementation:
- Loop through all healthy_validators
- Query each one's blockchain endpoint
- Track the state with the highest block count
- Return that state
This is a best-effort approach while block synchronization is being
established between validators.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Problem: Votes were only being submitted to one validator selected via
round-robin, then expected inter-validator broadcasting to propagate the
transaction. But inter-validator transaction broadcasting wasn't working
reliably.
Solution: Submit each vote to ALL healthy validators simultaneously.
This ensures every validator receives the transaction directly, making it
available for block creation regardless of inter-validator communication.
Benefits:
- No dependency on P2P transaction broadcasting
- All validators have same pending transaction pool
- Any validator can create blocks with all pending transactions
- More robust and simpler than trying to maintain P2P mesh
Implementation:
- Modified submit_vote() to loop through all healthy_validators
- Submit same JSON-RPC request to each validator
- Log results from each submission
- Require at least one successful submission
This is simpler and more reliable than the previous architecture.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Problem: The GET /api/votes/blockchain endpoint was returning the local
blockchain manager data instead of querying the PoA validators where votes
are actually being submitted.
This caused votes to appear successfully submitted (with block_hash from
validators) but not show up when querying the blockchain state, since the
query was hitting the wrong data source.
Solution: Update the /blockchain endpoint to:
1. First try to get blockchain state from PoA validators
2. Fall back to local blockchain manager if PoA unavailable
3. Add detailed logging for debugging
This ensures the blockchain state matches where votes are actually being
stored on the PoA network.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Add logging at each stage:
- Context manager entry/exit
- submit_vote() method entry
- Validator selection
- HTTP request details
- Response handling
This will help identify exactly where the vote submission is failing.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Add traceback and exception type logging to help diagnose why PoA
submission is failing silently and falling back to local blockchain.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Problem: Votes were being rejected by validators with 'Invalid data format'
error because the transaction data wasn't in the correct format.
Root cause: The validator's eth_sendTransaction endpoint expects the 'data'
field to be:
1. A hex string prefixed with '0x'
2. The hex-encoded JSON of a Transaction object containing:
- voter_id
- election_id
- encrypted_vote
- ballot_hash
- timestamp
Solution:
- Update BlockchainClient.submit_vote() to properly encode transaction data
as JSON, then hex-encode it with 0x prefix
- Add ballot_hash parameter to submit_vote() method
- Update both call sites in votes.py to pass ballot_hash
- Generate ballot_hash if not provided for safety
This ensures votes are now properly formatted and accepted by validators,
allowing them to be submitted to the blockchain instead of falling back to
local blockchain.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Changes:
- Add next-themes dependency for theme management
- Create ThemeProvider wrapper for app root layout
- Set dark mode as default theme
- Create ThemeToggle component with Sun/Moon icons
- Add theme toggle to home page navigation
- Add theme toggle to dashboard header
- App now starts in dark mode with ability to switch to light mode
Styling uses existing Tailwind dark mode variables configured in
tailwind.config.ts and globals.css. All existing components automatically
support dark theme.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
The POST /api/votes endpoint (used by frontend) was recording votes
in the database but NOT submitting them to the PoA blockchain. This
caused votes to appear in database but not on the blockchain.
Changes:
- Add vote submission to PoA validators in the simple endpoint
- Add fallback to local blockchain if PoA validators unreachable
- Include blockchain status in API response
- Use ballot hash as vote data for blockchain submission
This ensures votes are now submitted to the PoA blockchain when the
frontend votes, and users can see their votes on the blockchain.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
validator-2 was incorrectly configured to use port 8001 (should be 8002)
validator-3 was incorrectly configured to use port 8001 (should be 8003)
This was causing validator-2 and validator-3 to be unreachable from the
backend container, resulting in votes being submitted to the local fallback
blockchain instead of the PoA validators.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
The backend container needs to reach validators using their Docker service names
(validator-1, validator-2, validator-3) instead of localhost:PORT.
This fixes the 'validators unreachable' warning on backend startup.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit addresses critical issues preventing user registration:
1. Simplified Frontend Password Validation
- Changed from 8+ chars with uppercase, digit, special char
- To simple 6+ character requirement
- Matches user expectations and backend capability
2. Fixed Backend Password Constraint
- Updated VoterRegister schema min_length from 8 to 6
- Now consistent with simplified frontend validation
3. Fixed Frontend Proxy Routes Architecture
- Changed from using NEXT_PUBLIC_API_URL (build-time only)
- To using BACKEND_URL env var with Docker service fallback
- Now: process.env.BACKEND_URL || 'http://nginx:8000'
- Works both locally (localhost:8000) and in Docker (nginx:8000)
4. Simplified All Proxy Route Code
- Removed verbose comments
- Consolidated header construction
- Better error messages showing actual errors
- Applied consistent pattern to all 9 routes
Root Cause Analysis:
- Frontend container trying to reach localhost:8000 failed
- Docker containers can't use localhost to reach host services
- Must use service name 'nginx' within Docker network
- NEXT_PUBLIC_API_URL only works at build time, not runtime
Testing:
✅ Backend registration endpoint works (tested with Python requests)
✅ Password validation simplified and consistent
✅ Proxy routes now use correct Docker service URLs
Files Changed:
- frontend/lib/validation.ts (password requirements)
- backend/schemas.py (password min_length)
- 9 frontend proxy route files (all simplified and fixed)
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
This commit completes the voting system implementation with:
1. Frontend API Proxy Routes:
- Created 9 Next.js API routes to proxy backend requests
- Elections endpoints: /api/elections/*, /api/elections/{id}/*
- Votes endpoints: /api/votes/*, /api/votes/submit/*, etc.
- Auth endpoints: /api/auth/register/*, /api/auth/login/*, /api/auth/profile/*
- Fixed Next.js 15.5 compatibility with Promise-based params
2. Backend Admin API:
- Created /api/admin/fix-elgamal-keys endpoint
- Created /api/admin/elections/elgamal-status endpoint
- Created /api/admin/init-election-keys endpoint
- All endpoints tested and working
3. Database Schema Fixes:
- Fixed docker/create_active_election.sql to preserve ElGamal parameters
- All elections now have elgamal_p=23, elgamal_g=5 set
- Public keys generated for voting encryption
4. Documentation:
- Added VOTING_SYSTEM_STATUS.md with complete status
- Added FINAL_SETUP_STEPS.md with setup instructions
- Added fix_elgamal_keys.py utility script
System Status:
✅ Backend: All 3 nodes operational with 12 elections
✅ Database: ElGamal parameters initialized
✅ Crypto: Public keys generated for active elections
✅ API: All endpoints verified working
✅ Frontend: Proxy routes created (ready for rebuild)
Next Step: docker compose up -d --build frontend
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Moved specific routes (/blockchain, /debug/all, /active, /completed, /upcoming)
BEFORE generic routes (/{election_id}, /{election_id}/results, etc) so that
specific paths are matched first and don't get caught by the {election_id}
path parameter matcher.
Also removed duplicate /completed and /upcoming route definitions.
Routes now in correct order:
1. Specific paths: /debug/all, /active, /blockchain
2. Specific subpaths: /{id}/blockchain-verify, /{id}/candidates, /{id}/results
3. Generic: /{id}
The main.py was trying to import get_db for blockchain initialization
but it was missing from database.py. Added the get_db generator function
that creates and properly closes database sessions.
Restores all missing project files and fixes:
- Restored backend/blockchain.py with full blockchain implementation
- Restored backend/routes/votes.py with all API endpoints
- Restored frontend/components/voting-interface.tsx voting UI
- Fixed backend/crypto/hashing.py to handle both str and bytes
- Fixed pyproject.toml for Poetry compatibility
- All cryptographic modules tested and working
- ElGamal encryption, ZK proofs, digital signatures functional
- Blockchain integrity verification working
- Homomorphic vote counting implemented and tested
Phase 2 Backend API: ✓ COMPLETE
Phase 3 Frontend Interface: ✓ COMPLETE
Verification:
✓ Frontend builds successfully (12 routes)
✓ Backend crypto modules all import correctly
✓ Full voting simulation works end-to-end
✓ Blockchain records and verifies votes
✓ Homomorphic vote counting functional
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
- Added HistoriquePage component to display user's voting history with detailed statistics and vote cards.
- Created UpcomingVotesPage component to show upcoming elections with a similar layout.
- Developed CSS styles for both pages to enhance visual appeal and responsiveness.
- Integrated API calls to fetch user's votes and upcoming elections.
- Added a rebuild script for Docker environment setup and data restoration.
- Created a Python script to populate the database with sample data for testing.
