{"type":"video","version":"1.0","html":"<iframe src=\"https://www.loom.com/embed/a38330e102fc45ac91246d0631e3a378\" frameborder=\"0\" width=\"1280\" height=\"960\" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>","height":960,"width":1280,"provider_name":"Loom","provider_url":"https://www.loom.com","thumbnail_height":960,"thumbnail_width":1280,"thumbnail_url":"https://cdn.loom.com/sessions/thumbnails/a38330e102fc45ac91246d0631e3a378-c60bd0668798397d.gif","duration":217.862,"title":"Secure Task Management App - Walkthrough Video","description":"A modern, secure, and scalable task management application built with an Nx monorepo. This project features a robust Angular frontend styled with Tailwind CSS v4 and a NestJS backend API using TypeORM and SQLite/Postgres.\n\nHi, this is my Secure Task Management application.\n- It’s implemented as an Nx monorepo with an Angular 19 dashboard and a NestJS API.  \n- The primary focus is secure JWT authentication, hierarchical RBAC, and strict organization scoping for multi-tenant isolation.\n\n- I’ll start with a quick UI walkthrough, then cover the authentication and authorization flow, followed by the architecture and key trade-offs.\n- After logging in, authentication is handled by Supabase, which issues a JWT that is attached to all API requests.\n- The user lands on the project board where tasks can be created, updated, moved between columns using Angular CDK drag-and-drop, and deleted if the user’s role permits.\n- Task visibility is scoped to the user’s organization, so users only see data they’re authorized to access.\n- The analytics section provides a simple completion bar chart, and there’s support for dark mode and keyboard shortcuts for faster task actions.\n\n- In the audit log, every create, update, and delete operation is recorded with the user, action, resource, and timestamp.\nLooking at the network tab, each request includes an Authorization header with a Bearer token.\n\n\n- On the backend, NestJS uses a Passport-JWT strategy to validate the token against the Supabase secret.  \n- The token’s subject is mapped to the internal user entity and attached to the request context, which allows guards and services to enforce access control consistently.\n- RBAC is implemented using a custom `@Roles()` decorator and a `RolesGuard`.\n- The role hierarchy is Owner, Admin, and Viewer, with inheritance handled in the guard.  \n- Route handlers declare the required roles, and access is denied if the user does not meet the minimum role.\n- In addition to route-level protection, organization scoping is enforced at the query layer.  \n- Users only receive tasks belonging to their organization, while admins in a parent organization can view data from child organizations but not from unrelated tenants.  \n- This ensures proper multi-tenant isolation.\n\n- From an architectural perspective, Nx is used to enforce clear boundaries and shared contracts.  \n- Shared DTOs live in `libs/data`, which provides type safety across the frontend and backend.  \n- RBAC decorators and guards live in `libs/auth`, making them reusable, testable, and decoupled from feature modules.\n\n-Audit logging is implemented in the service layer so that every state-changing operation automatically records an audit entry without duplicating logic in controllers.\n\n-In terms of trade-offs, I used short-lived access tokens without refresh tokens due to time constraints.  \n-RBAC checks are performed on every request, so there is no caching layer yet.  \n-Authorization is implemented at the resource level rather than the field level to keep the model simple and correct.\n\n-Future improvements would include Redis-based RBAC caching, Postgres row-level security to push authorization closer to the data layer, refresh token rotation for stronger session security, and WebSocket support for real-time board updates.\n\n-Overall, this implementation prioritizes secure defaults, clear RBAC boundaries, and a scalable Nx architecture with shared types and reusable authorization logic.\n\nThank you."}