tercul-backend/internal/app/auth
Damir Mukimov d50722dad5
Some checks failed
Test / Integration Tests (push) Successful in 4s
Build / Build Binary (push) Failing after 2m9s
Docker Build / Build Docker Image (push) Failing after 2m32s
Test / Unit Tests (push) Failing after 3m12s
Lint / Go Lint (push) Failing after 1m0s
Refactor ID handling to use UUIDs across the application
- Updated database models and repositories to replace uint IDs with UUIDs.
- Modified test fixtures to generate and use UUIDs for authors, translations, users, and works.
- Adjusted mock implementations to align with the new UUID structure.
- Ensured all relevant functions and methods are updated to handle UUIDs correctly.
- Added necessary imports for UUID handling in various files.
2025-12-27 00:33:34 +01:00
..
.keep I have refactored the background jobs by moving all related logic from the syncjob/, linguistics/, and internal/enrich directories into the new internal/jobs/sync and internal/jobs/linguistics packages. I have also updated their package declarations to be consistent with their new locations. 2025-09-02 15:02:04 +00:00
commands_test.go Refactor ID handling to use UUIDs across the application 2025-12-27 00:33:34 +01:00
commands.go Refactor ID handling to use UUIDs across the application 2025-12-27 00:33:34 +01:00
doc.go Security Hardening and GraphQL Caching (#69) 2025-12-01 00:14:22 +01:00
main_test.go Refactor ID handling to use UUIDs across the application 2025-12-27 00:33:34 +01:00
queries_test.go Chore: Clean up lint warnings and improve code quality 2025-10-07 13:14:01 +00:00
queries.go feat: Complete all pending tasks from TASKS.md 2025-10-05 05:26:27 +00:00
README.md This commit introduces a series of significant improvements to bring the codebase closer to a production-ready state. 2025-10-08 17:25:02 +00:00
service.go Refactor: Introduce service layer for application logic 2025-09-09 02:28:25 +00:00

Auth Service

This package handles all user authentication and session management for the Tercul platform. It is responsible for registering new users, authenticating existing users, and managing JSON Web Tokens (JWTs).

Architecture Overview

The auth service is designed to be a self-contained unit for all authentication-related logic. It provides a clear API for other parts of the application to interact with user sessions.

Key Components

  • service.go: The main entry point for the auth service. It implements the Service interface and contains the core business logic for registration, login, logout, and token management.

  • commands.go: Contains the command handlers for all authentication-related actions, such as:

    • Register: Creates a new user account.
    • Login: Authenticates a user and issues a JWT.
    • Logout: Invalidates a user's session.
    • RefreshToken: Issues a new JWT for an active session.
    • ForgotPassword / ResetPassword: Handles the password reset flow.
    • VerifyEmail / ResendVerificationEmail: Manages email verification.
    • ChangePassword: Allows an authenticated user to change their password.
  • interfaces.go: Defines the Service and AuthRepository interfaces, establishing a clear contract for the service's capabilities and its data persistence requirements.

  • jwt.go (in internal/platform/auth): The service relies on the JWTManager from this platform package to handle the creation and validation of JWTs.

Usage

The auth.Service is primarily used by the GraphQL resolvers to handle authentication-related mutations.

Example: User Registration

// In a GraphQL resolver
registerInput := auth.RegisterInput{...}
authResponse, err := authService.Commands.Register(ctx, registerInput)

Example: User Login

// In a GraphQL resolver
loginInput := auth.LoginInput{...}
authResponse, err := authService.Commands.Login(ctx, loginInput)

Dependencies

  • internal/domain: Uses the core User domain entity.
  • internal/platform/auth: Relies on the JWTManager to handle all JWT operations. This is a critical dependency for session management.
  • Database: Persists user data via the UserRepository.
  • Logging: Uses the centralized logger from internal/platform/log.
  • OpenTelemetry: All service and command methods are instrumented for distributed tracing.