HyperionDocs
ArchitectureSolution Designs001 - Personal Account Module

Solution Design - Personal Account Module

Solution design for faculty personal account management

Personal Account Module - Solution Design

Purpose

University faculty members need a centralized system to manage their professional profiles. The Personal Account Module provides:

  1. Profile Management - Faculty can view and update their personal information
  2. Credential Tracking - Academic degrees, positions, and honors are recorded
  3. Department Assignments - Support for primary and joint positions across departments
  4. Public Directory - Guests can search and view public faculty information

Business Value

  • Centralizes faculty data previously scattered across spreadsheets
  • Provides public-facing directory for students and external parties
  • Enables accurate reporting for university administration
  • Foundation for activity tracking and rating calculations

Owners

  • Product Owner: University Administration
  • Development Team: NPP Portal Team

Flow Overview

User Profile Management Flow

┌─────────┐     ┌──────────┐     ┌─────────┐     ┌──────────┐
│ Teacher │────▶│   SPA    │────▶│   API   │────▶│    DB    │
└─────────┘     └──────────┘     └─────────┘     └──────────┘
     │               │                │                │
     │  1. Login     │                │                │
     │──────────────▶│                │                │
     │               │ 2. POST /auth/login             │
     │               │───────────────▶│                │
     │               │                │ 3. Validate    │
     │               │                │───────────────▶│
     │               │                │◀───────────────│
     │               │◀───────────────│                │
     │  4. JWT Token │                │                │
     │◀──────────────│                │                │
     │               │                │                │
     │  5. View Profile               │                │
     │──────────────▶│                │                │
     │               │ 6. GET /users/me                │
     │               │───────────────▶│                │
     │               │                │ 7. Fetch user  │
     │               │                │───────────────▶│
     │               │                │◀───────────────│
     │               │◀───────────────│                │
     │  8. Profile data               │                │
     │◀──────────────│                │                │

Scope

In Scope

  • User registration (admin-initiated)
  • Password setup via email token
  • Password reset flow
  • JWT authentication with refresh tokens
  • View own profile
  • Update own profile details
  • View own department assignments
  • Photo upload
  • Public user directory (guest access)
  • Search users by name/department
  • Admin: CRUD users
  • Admin: Assign users to departments
  • Admin: Manage dictionaries (degrees, positions, honors)

Out of Scope

  • Self-registration (users are created by admin)
  • LDAP/SSO integration (future ADR)
  • Bulk user import (separate feature)
  • Profile change history/audit log
  • Two-factor authentication

Risk

Technical Risks

RiskImpactMitigation
Password stored insecurelyHighBCrypt hashing with salt
Token theft enables account takeoverHighShort access token TTL (30min), refresh token rotation
Photo upload abuseMediumFile type validation, size limits, malware scanning
SQL injection in searchHighParameterized queries via JPA

Stability Concerns

  • Redis unavailability blocks login (refresh tokens)
  • Large photo uploads may cause timeouts
  • Concurrent profile updates need optimistic locking

Research

Password Reset Token Strategy

Evaluated options for password reset tokens:

  1. Random string stored in DB - simple but requires DB lookup
  2. Signed JWT with user ID - stateless but harder to revoke
  3. Random string in Redis with TTL - fast, auto-expires

Result: Option 3 (Redis) chosen for automatic expiration and consistency with auth token storage.

Photo Storage

Evaluated options:

  1. Database BLOB - simple, no external dependency
  2. Local filesystem - performant, but scaling issues
  3. Object storage (S3/MinIO) - scalable, CDN-ready

Result: Start with Option 2 (filesystem) with path stored in DB. Architecture allows migration to S3 later.

API Endpoints

Authentication

MethodEndpointAccessDescription
POST/auth/loginPublicAuthenticate user
POST/auth/refreshPublicRefresh access token
POST/auth/logoutAuthInvalidate refresh token
POST/auth/set-passwordPublicSet password with token
POST/auth/reset-passwordPublicRequest password reset

User Profile

MethodEndpointAccessDescription
GET/users/meAuthGet current user profile
PUT/users/meAuthUpdate current user
GET/users/me/detailsAuthGet extended profile
PUT/users/me/detailsAuthUpdate extended profile
POST/users/me/photoAuthUpload photo
DELETE/users/me/photoAuthRemove photo
PUT/users/me/passwordAuthChange password

User Management (Admin)

MethodEndpointAccessDescription
GET/usersAdminList all users
POST/usersAdminCreate user
GET/users/{id}AdminGet user by ID
PUT/users/{id}AdminUpdate user
DELETE/users/{id}AdminDeactivate user
POST/users/{id}/departmentsAdminAssign to department
DELETE/users/{id}/departments/{deptId}AdminRemove from department

Public Directory

MethodEndpointAccessDescription
GET/public/usersGuestList public profiles
GET/public/users/{uuid}GuestGet public profile
GET/public/departments/{id}/usersGuestUsers in department

Additional Requirements

Backend

  • User entity with BCrypt password hashing
  • UserDetails entity for extended profile
  • UserDepartment junction table with workload
  • JWT generation and validation service
  • Redis integration for token storage
  • Multipart file upload handling
  • Email service integration (password reset)

Frontend

  • Login page with form validation
  • Password setup/reset pages
  • Profile view page
  • Profile edit form
  • Photo upload with preview
  • Public directory with search
  • Admin user management table
  • Admin department assignment modal

Data Validation

FieldValidation
EmailValid format, max 255 chars, unique
LoginMax 255 chars, unique, auto-generated
PasswordMin 8 chars, complexity rules
Name fieldsRequired, max 255 chars each
PhotoMax 5MB, JPEG/PNG only

Additional Documentation