# 02 - M1.7 Revision Sheet & Interview Q&A

Short revision guide for **Milestone 1.7**.

---

## 1. Quick Summary

- **What We Built:** Implemented `POST /api/v1/session/init` backend endpoint, Pydantic session models, session repository layer, server-side HTTP `Origin` header validation, and client widget API integration.
- **HTTP Status Codes:** `201 Created` (success), `404 Not Found` (unknown siteId), `403 Forbidden` (unauthorized origin), `422 Unprocessable Entity` (invalid payload).
- **Database Persistence:** Persists session documents into MongoDB `sessions` collection.

---

## 2. 5 Key Interview Q&As

#### Q1: Why does the server generate the `sessionId` instead of the client widget?
**Answer:** Server-side generation guarantees unguessable, cryptographically secure UUID session IDs and prevents clients from forging session identifiers or hijacking existing sessions.

#### Q2: Why is the HTTP `Origin` header used for origin validation instead of a JSON payload parameter?
**Answer:** The HTTP `Origin` header is automatically set by the browser and cannot be modified by client JavaScript. JSON body parameters can easily be spoofed by malicious scripts.

#### Q3: What happens if a tenant `siteId` does not exist in MongoDB?
**Answer:** The endpoint returns `404 Not Found` with detail `"Tenant not found for siteId '...'"` and halts session creation.

#### Q4: How does the widget handle `sessionId` in M1.7?
**Answer:** In M1.7, the widget receives `sessionId` from `/session/init` and holds it in a runtime variable (`currentSessionId`). Persisting `sessionId` across page reloads in `localStorage` is implemented in M1.8.

#### Q5: What database collections exist in MongoDB after M1.7?
**Answer:** Two collections: `tenants` (storing website tenant accounts) and `sessions` (storing visitor session threads).