Files
ds-galo/openspec/changes/shared-album/specs/auth/spec.md
T
iu 2b2b342492 feat: implement shared-album multi-user photo album
Backend (Go/Gin/pgx): env config, pgx pool with retries, Garage S3 client
(path-style, region garage), embedded golang-migrate migrations, JWT auth with
refresh rotation, albums CRUD, members/roles/invites with no-escalation matrix,
photo upload + async imaging/goexif WebP variants, cursor pagination, presigned
URLs, likes/comments, SSE hub (album + personal), notifications, share links.

Frontend (SvelteKit 2 + Svelte 5 + Tailwind v4): API wrapper with 401 refresh,
auth store, all screens, Uploader/PhotoGrid/Lightbox/Comments, SSE client with
reconnect + REST catch-up, three themes + system via data-theme.

Deploy without Docker: Makefile builds the frontend into backend/static and
embeds it (go:embed) into a single statically linked binary; systemd unit and
nginx SSE example included.

Use gen2brain/webp (-tags nodynamic) instead of cgo kolesa-team/go-webp to keep
CGO_ENABLED=0 static builds; design.md/proposal.md updated accordingly.
2026-10-10 12:50:33 +03:00

48 lines
2.9 KiB
Markdown

# Spec Delta
## Purpose
Регистрация и аутентификация пользователей по email и паролю с выдачей краткоживущих и долгоживущих JWT-токенов.
## ADDED Requirements
### Requirement: Регистрация пользователя
Пользователь SHALL иметь возможность зарегистрироваться, указав email, пароль и имя. Пароль SHALL храниться в виде bcrypt-хэша.
#### Scenario: Успешная регистрация
- **WHEN** пользователь отправляет уникальный email, пароль и имя
- **THEN** система создаёт учётную запись и возвращает access- и refresh-токены
#### Scenario: Повторный email
- **WHEN** пользователь регистрируется с уже занятым email
- **THEN** система возвращает ошибку конфликта и не создаёт вторую запись
### Requirement: Вход по email и паролю
Пользователь SHALL иметь возможность войти, указав email и пароль.
#### Scenario: Успешный вход
- **WHEN** пользователь вводит верные email и пароль
- **THEN** система возвращает access- и refresh-токены
#### Scenario: Неверные учётные данные
- **WHEN** пользователь вводит неверный email или пароль
- **THEN** система возвращает 401, не раскрывая, какое именно поле неверно
### Requirement: Обновление access-токена
Пользователь SHALL иметь возможность обменять refresh-токен на новую пару токенов. Access-токен живёт 15 минут, refresh-токен — 30 дней.
#### Scenario: Валидный refresh-токен
- **WHEN** пользователь предоставляет действующий refresh-токен
- **THEN** система выдаёт новый access-токен и ротирует refresh-токен
#### Scenario: Недействительный refresh-токен
- **WHEN** пользователь предоставляет истёкший или отозванный refresh-токен
- **THEN** система возвращает 401
### Requirement: Выход из системы
Пользователь SHALL иметь возможность выйти, отозвав refresh-токен.
#### Scenario: Выход
- **WHEN** пользователь вызывает logout с действующим refresh-токеном
- **THEN** система отзывает refresh-токен, и его дальнейшее использование отклоняется