|
| 1 | +# GitHub Issue Context |
| 2 | + |
| 3 | +## Source |
| 4 | + |
| 5 | +- Repository: marciomyst/SmartMovieCatalog |
| 6 | +- Issue: #23 |
| 7 | +- URL: https://github.com/marciomyst/SmartMovieCatalog/issues/23 |
| 8 | +- State: OPEN |
| 9 | +- Created: 05/03/2026 19:37:28 |
| 10 | +- Updated: 05/03/2026 19:44:54 |
| 11 | +- Milestone: M1 — Core Movie Catalog |
| 12 | + |
| 13 | +## Title |
| 14 | + |
| 15 | +Authentication login screen |
| 16 | + |
| 17 | +## Labels |
| 18 | + |
| 19 | +- type:feature |
| 20 | +- priority:high |
| 21 | +- area:api |
| 22 | +- area:frontend |
| 23 | +- area:ui |
| 24 | +- area:security |
| 25 | +- v1 |
| 26 | + |
| 27 | +## Assignees |
| 28 | + |
| 29 | +_No assignees_ |
| 30 | + |
| 31 | + |
| 32 | + |
| 33 | +## Issue Body |
| 34 | + |
| 35 | +## Summary |
| 36 | + |
| 37 | +Implement and document the Angular authentication login screen for Smart Movie Catalog. |
| 38 | + |
| 39 | +<img width="1338" height="737" alt="Image" src="https://github.com/user-attachments/assets/1580050b-6599-47c0-b4bd-a2fc7736ca96" /> |
| 40 | + |
| 41 | +This issue covers the first frontend authentication surface: a dark cinematic login page that authenticates against the existing backend auth API and creates an in-memory frontend session. |
| 42 | + |
| 43 | +## Goal |
| 44 | + |
| 45 | +Allow users to authenticate from the Angular SPA using local email/password credentials and load their current user context before entering authenticated product flows. |
| 46 | + |
| 47 | +## Scope |
| 48 | + |
| 49 | +- Add the authentication login screen as the current SPA entry surface. |
| 50 | +- Keep the UI aligned with `frontend/DESIGN.md`: dark mode, cinematic visual direction, responsive layout, and Material Symbols icons. |
| 51 | +- Use an Angular reactive form with client-side validation for email and password. |
| 52 | +- Consume `POST /api/auth/authenticate` through a typed frontend API service. |
| 53 | +- After successful authentication, call `GET /api/auth/me` using the returned bearer token. |
| 54 | +- Keep `HttpClient` calls isolated outside UI components. |
| 55 | +- Store the authenticated session in memory only through an auth session store. |
| 56 | +- Map backend `400 ValidationProblemDetails` to field-level frontend validation feedback. |
| 57 | +- Keep backend `401 Unauthorized` responses generic in the UI to avoid account enumeration. |
| 58 | +- Update documentation for frontend auth structure, security posture, API consumption, testing, and ADR coverage. |
| 59 | + |
| 60 | +## API Usage |
| 61 | + |
| 62 | +```http |
| 63 | +POST /api/auth/authenticate |
| 64 | +``` |
| 65 | + |
| 66 | +Request: |
| 67 | + |
| 68 | +```json |
| 69 | +{ "email": "user@example.com", "password": "Password123!" } |
| 70 | +``` |
| 71 | + |
| 72 | +Successful login then calls: |
| 73 | + |
| 74 | +```http |
| 75 | +GET /api/auth/me |
| 76 | +Authorization: Bearer <accessToken> |
| 77 | +``` |
| 78 | + |
| 79 | +Local Angular development should use same-origin `/api` paths through `frontend/src/proxy.conf.js`. |
| 80 | + |
| 81 | +## Acceptance Criteria |
| 82 | + |
| 83 | +- Login screen renders as the SPA entry screen. |
| 84 | +- The page is responsive on mobile and desktop. |
| 85 | +- Email and password fields use Angular reactive form validation. |
| 86 | +- Password visibility can be toggled with an accessible icon button. |
| 87 | +- Submit calls `POST /api/auth/authenticate` with `email` and `password`. |
| 88 | +- Successful authentication calls `GET /api/auth/me` with the bearer token. |
| 89 | +- Successful authentication stores `accessToken`, `accessTokenExpiresAtUtc`, and current user data in memory. |
| 90 | +- Bearer token is not persisted in `localStorage` or `sessionStorage`. |
| 91 | +- `400 ValidationProblemDetails` displays field-level feedback. |
| 92 | +- `401 Unauthorized` displays a generic authentication error. |
| 93 | +- UI components do not call `HttpClient` directly. |
| 94 | +- Frontend auth contracts stay aligned with `SmartMovieCatalog.Contracts.Auth`. |
| 95 | +- Tests cover rendering, validation, password visibility, API calls, bearer header behavior, and unauthorized errors. |
| 96 | +- Documentation reflects the implemented auth screen and in-memory session strategy. |
| 97 | + |
| 98 | +## Technical Notes |
| 99 | + |
| 100 | +- Frontend auth code should live under `frontend/src/app/auth`. |
| 101 | +- Use typed API boundaries such as `AuthApi` and `auth.models.ts`. |
| 102 | +- Use an in-memory session store rather than browser storage. |
| 103 | +- Keep `/api` as the frontend request base so the same code works with Angular proxy locally and ASP.NET Core SPA hosting in runtime. |
| 104 | +- Any persistent session or refresh-token behavior requires a separate security decision. |
| 105 | + |
| 106 | +## Out of Scope |
| 107 | + |
| 108 | +- Refresh tokens. |
| 109 | +- Persistent browser sessions. |
| 110 | +- Route guards and authenticated app shell navigation. |
| 111 | +- Logout flow. |
| 112 | +- Registration. |
| 113 | +- Password recovery. |
| 114 | +- External identity providers. |
| 115 | +- Role-specific authorization UI. |
| 116 | + |
| 117 | + |
| 118 | +## Comments |
| 119 | + |
| 120 | +_No comments_ |
| 121 | + |
| 122 | +## Instructions for Spec Kit |
| 123 | + |
| 124 | +Use this GitHub issue as the primary source of truth. |
| 125 | + |
| 126 | +Convert the issue into a Spec Kit feature specification before creating the implementation plan. |
| 127 | + |
| 128 | +Preserve: |
| 129 | + |
| 130 | +- business goal; |
| 131 | +- user stories; |
| 132 | +- acceptance criteria; |
| 133 | +- technical constraints; |
| 134 | +- non-goals; |
| 135 | +- dependencies; |
| 136 | +- open questions. |
| 137 | + |
| 138 | +If information is missing, add it under a clearly marked **Clarifications Needed** section instead of inventing requirements. |
| 139 | + |
| 140 | +If the issue conflicts with existing project documentation, explicitly call out the conflict. |
| 141 | + |
| 142 | +Prefer a small, incremental implementation plan aligned with the repository's existing architecture, folder structure, language, framework, and conventions. |
0 commit comments