From 3bb0ca2e58168b28c5e49763acd25f531fb8a78d Mon Sep 17 00:00:00 2001 From: Peter Stone Date: Tue, 20 Jan 2026 15:27:15 -1000 Subject: Add project documentation Include design system guidelines, Phase 3 roadmap, code quality review, proposed README, and authentication ADR. Co-Authored-By: Claude Opus 4.5 --- docs/adr/001-authentication-strategy.md | 35 +++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 docs/adr/001-authentication-strategy.md (limited to 'docs/adr/001-authentication-strategy.md') diff --git a/docs/adr/001-authentication-strategy.md b/docs/adr/001-authentication-strategy.md new file mode 100644 index 0000000..e3610f3 --- /dev/null +++ b/docs/adr/001-authentication-strategy.md @@ -0,0 +1,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. -- cgit v1.2.3