51 lines
1.6 KiB
Markdown
51 lines
1.6 KiB
Markdown
# NFR Requirements Plan — Unit 0: Backend Prerequisites
|
|
|
|
## Context
|
|
Unit 0 modifies existing .NET 10 backend endpoints. Most NFRs are inherited from the existing system. Only security-specific NFRs for the cookie/CORS changes require clarification.
|
|
|
|
## Plan Checklist
|
|
- [x] Functional design artifacts analyzed
|
|
- [x] Questions generated
|
|
- [x] Questions answered
|
|
- [x] nfr-requirements.md generated
|
|
- [x] tech-stack-decisions.md generated
|
|
|
|
---
|
|
|
|
## Clarification Questions
|
|
|
|
---
|
|
|
|
### Question 1: Refresh token lifetime
|
|
What should the refresh token lifetime be?
|
|
|
|
A) 7 days (current default — check actual `RefreshToken` expiry in the codebase)
|
|
B) 30 days
|
|
C) 90 days
|
|
X) Other (specify in days after [Answer]: tag)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Question 2: Rate limiting on auth endpoints
|
|
Should rate limiting be applied to the auth endpoints (login, refresh) to prevent brute-force attacks?
|
|
|
|
A) Yes — add rate limiting now as part of Unit 0 (e.g. via ASP.NET Core built-in rate limiter)
|
|
B) No — rate limiting is out of scope for this unit; document as future work
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Question 3: Error response format on auth failures
|
|
What should the error response body look like when auth fails (wrong password, invalid token, missing cookie)?
|
|
|
|
A) RFC 9457 ProblemDetails (standard ASP.NET format: `type`, `title`, `status`, `detail`)
|
|
B) Simple JSON `{ "message": "..." }` (consistent with current API error format)
|
|
C) Use the existing GlobalExceptionHandler format from `SlpModularCms.Api/Infrastructure/`
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|