-
Notifications
You must be signed in to change notification settings - Fork 2
API Client Management System #44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
RichardCMX
wants to merge
45
commits into
main
Choose a base branch
from
feature/client-management
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…as HH:MM:SS; validate stop_id; add Fuseki flags and DAL docs; add /api/schedule/departures/ endpoint
…tures endpoint; tests(api): add tests for DAL-backed schedule departures
…sts package __init__
…CACHE_TTL_SECONDS and pass via factory
…test; add tiny TTL sample
…add Fuseki dev guide and update README/architecture; fix duplicate FUSEKI_ENDPOINT
…tion (LimitOffsetPagination, page size 50)\n- Add /api/alerts route (ServiceAlertViewSet)\n- Add /api/arrivals endpoint integrating with ETAS_API_URL (Project 4)\n- Add /api/status endpoint reporting DB/Redis/Fuseki health\n- Update OpenAPI (datahub.yml) for pagination + new endpoints
…vals endpoint tests with mocked upstream
…ema to drf-spectacular
…Message, StopTimeUpdate to real model fields
…, stop-time-updates), pagination, OpenAPI docs, ETAs config, and testing instructions
…rules, feed-messages, stop-time-updates; polish examples for core endpoints
- Implement /api/search/ endpoint with ranking for stops and routes - Support for fuzzy text matching with relevance scoring - Configurable search types (stops, routes, all) - Limit and pagination support - Feed-specific search capability - Add /api/health/ endpoint for basic health checks - Simple status check returning 200 OK - Minimal response for lightweight monitoring - Add /api/ready/ endpoint for readiness checks - Database connectivity verification - Current feed availability check - Returns 503 when not ready to serve requests - Comprehensive test coverage for all new endpoints - Search functionality tests with various scenarios - Health endpoint validation tests - Edge cases and error handling tests - Full OpenAPI documentation integration - Proper error handling and validation - Follows existing code patterns and conventions
- Fix missing FloatField import in views.py for search functionality - Add comprehensive edge case tests for search: - Case insensitivity testing - Special characters and Unicode handling - Numbers and symbols in queries - Very long query handling - Add additional health endpoint test for multiple current feeds - Ensure robust error handling and graceful degradation
- Add custom API root view to include search, health, and ready endpoints - Update /api/ to show all endpoints including new search and health services - Add comprehensive README documentation for Issue #28: - Search API with intelligent ranking and fuzzy matching - Health monitoring endpoints for load balancers and Kubernetes - Complete usage examples with curl commands - Response format documentation - Integration examples (Docker health checks, K8s probes) The API root now shows: - search: http://localhost:8000/api/search/ - health: http://localhost:8000/api/health/ - ready: http://localhost:8000/api/ready/
✨ Features: - Add djangorestframework-simplejwt dependency for JWT support - Implement user registration endpoint with JWT token generation - Add custom JWT login/refresh views with user information - Create user profile endpoint requiring authentication 🔐 Security: - Configure JWT with 1-hour access tokens and 7-day refresh tokens - Apply authentication requirements to all GTFS data CRUD endpoints - Keep public endpoints (health, search, arrivals) accessible without auth - Add proper 401 error responses with detailed messages 🧪 Testing: - Add comprehensive JWT authentication test suite - Test user registration, login, token refresh, and profile access - Verify endpoint protection and public endpoint accessibility - All 10 tests passing successfully 📝 API Endpoints: - POST /api/auth/register/ - Register new user - POST /api/auth/login/ - Login and get JWT tokens - POST /api/auth/refresh/ - Refresh access token - GET /api/auth/profile/ - Get authenticated user profile Addresses issue #30 acceptance criteria: 'JWT for registered clients'
✨ JWT Authentication Features: - User registration with validation (username, email, password confirmation) - JWT token-based login with access/refresh token pairs - Token refresh functionality for seamless auth renewal - Protected user profile endpoint with authentication - Custom JWT views with enhanced error handling and user data - Comprehensive test suite (10 tests) covering all auth scenarios 🛡️ Rate Limiting Implementation: - Comprehensive rate limiting across all API endpoints - Tiered rate limiting strategy: • Light endpoints (health/ready): 100 req/min • Medium endpoints (arrivals/schedule): 60 req/min • Heavy endpoints (search): 30 req/min • Auth endpoints: 5-20 req/hour for sensitive operations - IP-based rate limiting with configurable limits - Proper 429 error responses with retry information - Rate limiting can be disabled via RATELIMIT_ENABLE setting - Unified rate_limiting.py module with both simple and decorator approaches 🧪 Testing & Quality: - 20 comprehensive tests (10 JWT auth + 10 rate limiting) - All tests passing with 100% success rate - Test coverage for edge cases and error scenarios - Organized test structure in api/tests/ directory ⚙️ Configuration: - Added django-ratelimit dependency (v4.1.0) - JWT settings configured in Django settings - Environment-based rate limiting configuration - Backward compatible implementation 🔧 Technical Implementation: - RESTful API design with proper HTTP status codes - DRF integration with custom authentication classes - Clean separation of concerns between auth and rate limiting - Documentation-ready with OpenAPI schema integration - Production-ready error handling and validation This implementation provides robust authentication and API protection suitable for production deployment with comprehensive test coverage.
…ation 📚 Documentation Updates: - Enhanced README.md with detailed authentication and rate limiting sections - Added step-by-step JWT authentication workflow with cURL examples - Documented rate limiting tiers and configuration options - Updated security checklist for production deployment - Added environment variable documentation for new features 📝 CHANGELOG.md Creation: - Comprehensive changelog following Keep a Changelog format - Detailed documentation of JWT authentication implementation - Complete rate limiting feature documentation with technical details - Test coverage documentation (20 tests, 100% passing) - Security enhancements and configuration examples - Performance impact analysis and compatibility information 🔧 Features Documented: - JWT user registration, login, token refresh, and profile endpoints - Tiered rate limiting across all API endpoints (14 endpoints protected) - Security configuration with environment-based settings - Production deployment considerations and security checklist This documentation update provides complete guidance for using the new authentication and rate limiting features introduced in the previous commit.
- Add client registration and API key management models - Set up admin interface for client management - Implement rate limiting and usage metrics middleware - Configure settings for client quotas and tracking Signed-off-by: RichardCMX <richardcm1157@gmail.com>
- Added complete client management section to README.md - Updated CHANGELOG.md with detailed feature documentation - Documented management commands, API key rotation, and status management - Added tier/quota tables, usage metrics tracking, and cleanup procedures - Included authenticated request examples and client model reference
- Added default='' to description TextField to prevent NULL values - Ensures consistent behavior when creating clients without description
- Remove Fuseki Docker service from docker-compose.yml - Remove fuseki_data volume - Delete storage/fuseki_schedule.py implementation - Delete api/tests/test_fuseki_schedule.py integration tests - Remove docker/fuseki/ configuration directory - Remove docs/dev/fuseki.md documentation - Update storage/factory.py to use only PostgreSQL repository - Remove FUSEKI_ENABLED and FUSEKI_ENDPOINT from settings.py - Remove Fuseki environment variables from .env.local.example - Update README.md and docs/architecture.md to remove Fuseki references PostgreSQL with Redis caching is now the sole storage backend.
- Document Data Access Layer implementation - Document new /api/schedule/departures/ endpoint - Document Redis caching configuration - Document Fuseki removal - Follow Keep a Changelog format
- Add class-level docstring explaining DAL testing - Document setUp method for test data preparation - Add docstrings for test_returns_404_when_stop_missing - Add docstrings for test_returns_departures_with_expected_shape - Improve test readability and maintainability
- Document test structure and organization - Explain test coverage for schedule departures endpoint - Provide examples for running tests - Document test data setup approach - Add guidelines for adding new tests
- Document /api/arrivals/ endpoint with ETA service integration - Document /api/status/ health check endpoint - Document /api/alerts/, /api/feed-messages/, /api/stop-time-updates/ - Document global pagination implementation - Document ETAS_API_URL configuration - Document comprehensive test suite for arrivals endpoint
- Add class-level docstring explaining ETA service integration testing - Document test_arrivals_returns_expected_shape - Document test_arrivals_propagates_upstream_error - Document test_arrivals_requires_stop_id - Document test_arrivals_accepts_wrapped_results_object - Document test_arrivals_handles_unexpected_upstream_structure_as_empty_list - Document limit validation tests - Document test_arrivals_returns_501_if_not_configured
- Add test_arrivals.py documentation - Document all 9 test cases for arrivals endpoint - Add examples for running arrivals tests - Document mocked HTTP request testing approach - Update coverage section with new test areas - Add unittest.mock to dependencies
- Update search queries to use __unaccent lookup for accent-insensitive matching - Support multilingual searches (Spanish, Portuguese, etc.) - Searches like 'San José' now match 'San Jose' and vice versa - Trigram similarity now operates on unaccented text for better fuzzy matching This improves search experience for Costa Rican transit data with accented characters.
BUG DISCOVERED: Issue #28 (search/autocomplete endpoints) implemented TrigramSimilarity for fuzzy text matching but never created the required PostgreSQL pg_trgm extension. The code silently fell back to basic string matching (icontains) via try/except blocks in api/views.py lines 1064-1104 and 1125-1179. This bug went undetected because: - Original tests validated API response structure, not trigram functionality - Exception handling masked the missing extension - Fallback logic allowed endpoints to return results IMPACT: - Search accuracy degraded (no fuzzy matching) - Search performance reduced (no trigram indexing) - Feature deployed incomplete FIX: Add PostgreSQL extension setup for both main and test databases: 1. docker/db/init.sql - Creates pg_trgm extension in dev/prod database on first container run - Mounted via docker-compose.yml at /docker-entrypoint-initdb.d/ - Enables TrigramSimilarity queries in search endpoints 2. datahub/test_runner.py - Custom Django test runner (InfobusTestRunner) - Creates pg_trgm extension in isolated test database - Required because Django doesn't copy extensions to test DB 3. datahub/settings.py - Configure TEST_RUNNER to use InfobusTestRunner - Ensures extensions available during test execution 4. docker-compose.yml - Mount init.sql to PostgreSQL initialization directory - Extension created automatically on database first start VERIFICATION: Comprehensive integration tests now verify actual trigram functionality instead of just API response structure, catching this missing setup. Resolves incomplete implementation from commit ea877e2 (Issue #28).
- Add SpectacularSwaggerView to api/urls.py - Available at /api/docs/swagger/ - Provides interactive forms for testing all API endpoints - Complements existing ReDoc documentation at /api/docs/
- Document /api/search/ with fuzzy matching and unaccent support - Document /api/health/ and /api/ready/ endpoints - Document PostgreSQL extensions (pg_trgm, unaccent) - Document Swagger UI and ReDoc integration - Document comprehensive test suites
- Add multilingual search documentation with unaccent extension - Document accent-insensitive search (San Jose matches San José) - Add Interactive API Documentation section - Document Swagger UI at /api/docs/swagger/ - Document ReDoc and DRF Browsable API - Improve search feature descriptions
Resolved conflicts in CHANGELOG.md and datahub/settings.py by keeping both sets of configurations: - Kept JWT and rate limiting configs from auth-rate-limits - Kept TEST_RUNNER and security settings from search-health-endpoints - Combined both branches' features
- Document test_jwt_auth.py with 10 test cases - Document test_rate_limiting.py with 10 test cases - Update test dependencies with JWT and Redis requirements - Update test coverage section with security features - Add test running examples for new test files
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Implements comprehensive API client management with key registration, usage tracking, tier-based access control, and lifecycle management. Enables systematic tracking and management of API consumers with rich analytics and administrative controls.
Related Issues
Closes #31
Changes Made
🔑 Client Management System
Client Model - Complete API consumer management
ClientUsage Model - Detailed usage tracking
🎛️ Django Admin Interface
ClientAdmin - Comprehensive management dashboard
ClientUsageAdmin - Read-only analytics
📊 Usage Tracking
/api/*endpoint requestscapture_api_usage()function⚙️ Management Commands
manage_clients - Complete client lifecycle management
create: Create new API clients with full configurationlist: Display all clients in formatted tablerotate-key: Regenerate API keys for securityactivate: Activate suspended/inactive clientssuspend: Temporarily suspend client accessrevoke: Permanently revoke client accessusage: View detailed usage statisticscleanup_usage - Database maintenance
🔐 Security Features
secretsmodule📈 Analytics & Reporting
get_usage_summary()method with period support:Technical Implementation
Database Migrations:
ClientandClientUsagemodelsMiddleware Integration:
APIUsageTrackingMiddlewareregistered inMIDDLEWAREsettingAdmin Customization:
Integration with Existing Features
Documentation
README.mdwith client management sectionCHANGELOG.mdwith comprehensive feature documentationTesting Results
All existing tests pass. Client management features can be tested via Django admin and management commands.
Migration Path
python manage.py migrateUsage Examples
Files Modified
api/models.py- Added Client and ClientUsage modelsapi/admin.py- Added ClientAdmin and ClientUsageAdminapi/middleware.py- New APIUsageTrackingMiddlewareapi/rate_limiting.py- Enhanced with capture_api_usage functionapi/management/commands/manage_clients.py- New management commandapi/management/commands/cleanup_usage.py- New cleanup commanddatahub/settings.py- Middleware and admin registrationREADME.md- Client management documentationCHANGELOG.md- Feature documentationSecurity Considerations
secretsmodulePerformance Impact
Backward Compatibility
Checklist
Next Steps
After merging, this branch serves as the base for:
feature/security-performance- Additional security and performance enhancementsfeature/admin-panel-metrics- Enhanced admin panel with metrics dashboard