87 lines
3.5 KiB
Markdown
87 lines
3.5 KiB
Markdown
# Functional Design Plan — Unit 0: Backend Prerequisites
|
|
|
|
## Unit Context
|
|
- **Unit**: Unit 0 — Backend Prerequisites
|
|
- **Type**: .NET backend changes
|
|
- **Stories**: US-02 (partial — cookie support), US-06 (partial), US-07 (partial)
|
|
- **Deliverables**:
|
|
- CORS policy via `appsettings.json`
|
|
- `AuthController` updated for httpOnly cookie (login/refresh/revoke)
|
|
- `RefreshTokenRequest.cs` removed
|
|
- `TokenResponse` updated with `Name` property
|
|
- `appsettings.json` + `appsettings.Development.json` updated
|
|
|
|
## Plan Checklist
|
|
- [x] Unit context analyzed
|
|
- [x] Questions generated
|
|
- [x] Questions answered
|
|
- [x] business-logic-model.md generated
|
|
- [x] business-rules.md generated
|
|
- [x] domain-entities.md generated
|
|
|
|
---
|
|
|
|
## Clarification Questions
|
|
|
|
Please answer the following questions by filling in the letter choice after the `[Answer]:` tag.
|
|
|
|
---
|
|
|
|
### Question 1: Cookie SameSite policy
|
|
The refresh token cookie will use `SameSite=Strict`. Is this correct, or should it be `SameSite=Lax`?
|
|
|
|
- `SameSite=Strict` — the cookie is only sent when the request originates from the exact same site (most secure; may cause issues if the login page is linked from an external source)
|
|
- `SameSite=Lax` — the cookie is sent on top-level navigations (e.g. clicking a link) but not on cross-site sub-requests (good balance of security and usability)
|
|
|
|
A) SameSite=Strict (as currently designed)
|
|
B) SameSite=Lax (slightly more permissive, still secure)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Question 2: Cookie Secure flag in development
|
|
In local development (HTTP, not HTTPS), the `Secure` flag on the cookie will cause the browser to reject the cookie. How should this be handled?
|
|
|
|
A) Use `Secure = true` always — developer must use HTTPS locally (e.g. via `dotnet dev-certs`)
|
|
B) Set `Secure` based on environment: `true` in Production, `false` in Development
|
|
C) Set `Secure = request.IsHttps` — automatically adapts to the current request protocol
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: B
|
|
|
|
---
|
|
|
|
### Question 3: TokenResponse — Name field source
|
|
The `TokenResponse` needs a `Name` field for the user's display name. `ApplicationUser` has `UserName` (from IdentityUser) but no dedicated display name field. What should `Name` return?
|
|
|
|
A) `user.UserName` — the username is used as the display name
|
|
B) `user.Email` — the email is used as the display name
|
|
C) `user.UserName ?? user.Email` — use UserName if set, fall back to Email
|
|
X) Other — add a dedicated `DisplayName` property to `ApplicationUser` (describe below)
|
|
|
|
[Answer]: C
|
|
|
|
---
|
|
|
|
### Question 4: Revoke endpoint — authentication requirement
|
|
The current `Revoke` endpoint requires a valid Bearer token (`[Authorize]`). With the cookie-based flow, should this still require authentication?
|
|
|
|
A) Yes — keep `[Authorize]` requirement (user must have a valid access token to revoke; most secure)
|
|
B) No — remove `[Authorize]` (allows revoking even after access token expires; better UX for logout after expiry)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A, but make the UX still seemless and make it refresh in the background while logging out. Maybe adding a text along the line of "Securely logging out..." gives some more time.
|
|
|
|
---
|
|
|
|
### Question 5: CORS — allowed HTTP methods
|
|
Which HTTP methods should the CORS policy allow?
|
|
|
|
A) Only the methods used by the API: GET, POST, PUT, DELETE, OPTIONS
|
|
B) All methods: `AllowAnyMethod()` (simpler, allows future endpoints without CORS changes)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|