1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
# ADR 001: Authentication Strategy
## Status
Accepted
## Context
The application is being prepared for deployment to a public server. Currently, it has no authentication mechanism. We need to secure the application to prevent unauthorized access to personal task data (Todoist, Trello, etc.).
## Decision
We will implement **Session-Based Authentication** using server-side sessions stored in SQLite.
### Technical Details:
1. **Session Management:** Use `alexedwards/scs` (v2) for session management.
* It provides a robust, secure implementation of session cookies.
* It supports SQLite as a backing store, simplifying infrastructure (no Redis needed).
2. **User Storage:** Create a `users` table in the existing SQLite database.
* Columns: `id`, `username`, `password_hash`, `created_at`.
3. **Password Hashing:** Use `bcrypt` (via `golang.org/x/crypto/bcrypt`) for hashing passwords.
4. **Middleware:** Implement a middleware function to protect routes.
* Public routes: `/login`, `/static/*`.
* Protected routes: `/`, `/api/*`, etc.
## Consequences
* **Pros:**
* Simple architecture (keeps everything in SQLite).
* Standard, well-understood security model.
* `scs` handles cookie security (HttpOnly, Secure, SameSite) automatically.
* **Cons:**
* Stateful (sessions in DB), but acceptable for this scale.
* Requires managing a user table and password resets (though we will start with manual user creation).
## Alternatives Considered
* **Basic Auth:** Too simple, poor UX (browser popup), hard to log out.
* **OAuth (Google/GitHub):** Overkill for a single-user/small-group app initially. Adds external dependencies and configuration complexity.
* **JWT (Stateless):** Adds complexity with token revocation and refresh tokens. Session-based is simpler for a server-rendered app.
|
