Aakash Request New Account Backend

[aakashg00]

Resolves #240
Adds endpoints for requestNewAccount, getAllNewAccountRequest, and removeNewAccountRequestById, in addition to input validation and e2e tests in API Gateway and DB Service

[greptile-apps]

Greptile Summary

Implements backend endpoints for new account request management, including the ability to submit, retrieve, and delete account requests. The implementation adds proper database schema, gRPC services, REST endpoints, input validation, and comprehensive e2e tests.

Key Changes:

• Added NewAccountRequest table with migration and Prisma schema
• Created gRPC AccountRequestService with three RPC methods
• Implemented REST endpoints: POST, GET, and DELETE /auth/account-request
• Added input validation for email, password (min 6 chars), and userType
• Protected GET and DELETE endpoints with admin/superadmin authorization
• Password hashing using bcrypt with 10 salt rounds
• Comprehensive e2e tests for both API Gateway and DB Service

Critical Issues:

• Hashed passwords are exposed in all API responses (GET, POST, DELETE), creating a security vulnerability that enables offline brute-force attacks
• Database schema lacks @unique constraint on email field, allowing duplicate requests

Backend Checklist Summary:

• ✅ API endpoints work as intended
• ✅ Uses async/await instead of promises
• ✅ Uses try/catch blocks for error handling (in service layer)
• ✅ Uses status codes correctly
• ✅ Schemas and queries are easily extensible
• ✅ Input is appropriately validated
• ⚠️ Schemas could be stricter (missing unique constraint on email)
• ✅ Handles edge cases (non-existent ID, invalid userType)
• ✅ Clear separation of database functionalities and API endpoints

Confidence Score: 2/5

• This PR has a critical security vulnerability that must be addressed before merging
• The implementation is well-structured with proper validation, tests, and authorization, but exposes hashed passwords in all API responses. Even though passwords are hashed, exposing them enables offline brute-force attacks and violates security best practices. This is a critical security flaw that prevents the PR from being safe to merge.
• Pay close attention to packages/proto/definitions/user.proto and packages/db-service/src/modules/auth/auth.controller.ts - password field must be removed from responses

Important Files Changed

Filename	Overview
packages/proto/definitions/user.proto	Added new AccountRequestService with three RPC methods and message definitions for account request management
packages/db-service/prisma/schema.prisma	Added NewAccountRequest model with fields for email, name, password, userType, projectName, and createdAt
packages/db-service/src/modules/auth/auth.controller.ts	Implements AccountRequestService RPC methods with bcrypt password hashing, but exposes hashed passwords in responses
packages/api-gateway/src/models/registration.dto.ts	Defines DTOs with proper validation for account requests, including email, password (min 6 chars), and userType constraints
packages/api-gateway/src/modules/auth/auth.controller.ts	Added three endpoints for account request management with authentication for GET/DELETE operations

Sequence Diagram

sequenceDiagram
    participant User
    participant API Gateway
    participant DB Service
    participant Database

    Note over User,Database: Create Account Request Flow
    User->>API Gateway: POST /auth/account-request
    API Gateway->>API Gateway: Validate DTO (email, password, userType)
    API Gateway->>DB Service: createAccountRequest gRPC
    DB Service->>DB Service: Hash password (bcrypt)
    DB Service->>Database: INSERT NewAccountRequest
    Database-->>DB Service: Created record
    DB Service-->>API Gateway: NewAccountRequest (with password hash)
    API Gateway-->>User: 201 Created (with password hash)

    Note over User,Database: Get All Requests Flow (Admin only)
    User->>API Gateway: GET /auth/account-request + credentials
    API Gateway->>API Gateway: Authenticate user via middleware
    API Gateway->>API Gateway: Check user.type != USER
    API Gateway->>DB Service: getAllAccountRequests gRPC
    DB Service->>Database: SELECT * FROM NewAccountRequest
    Database-->>DB Service: All records
    DB Service-->>API Gateway: NewAccountRequests array (with password hashes)
    API Gateway-->>User: 200 OK (with password hashes)

    Note over User,Database: Delete Request Flow (Admin only)
    User->>API Gateway: DELETE /auth/account-request/:id + credentials
    API Gateway->>API Gateway: Authenticate user via middleware
    API Gateway->>API Gateway: Check user.type != USER
    API Gateway->>API Gateway: Parse and validate ID
    API Gateway->>DB Service: deleteAccountRequest gRPC
    DB Service->>Database: SELECT WHERE id = ?
    Database-->>DB Service: Existing record or null
    alt Record exists
        DB Service->>Database: DELETE WHERE id = ?
        Database-->>DB Service: Deleted record
        DB Service-->>API Gateway: Deleted NewAccountRequest
        API Gateway-->>User: 200 OK
    else Record not found
        DB Service-->>API Gateway: NOT_FOUND error
        API Gateway-->>User: 404 Not Found
    end

Loading

_{Last reviewed commit: aaeb9dd}

[greptile-apps]

_{10 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[llam36]

LGTM!