Files

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

2.9 KiB

Raw Blame History

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-токен, и его дальнейшее использование отклоняется

2.9 KiB Raw Blame History