auth_service¶

1. Назначение¶

auth_service реализует регистрацию, вход, выход, выдачу токена и профиль текущего пользователя. Сервис является источником кастомной модели пользователя для остальных сервисов (AUTH_USER_MODEL = auth_app.User).

2. API-каталог¶

Базовый префикс: /api/.

Метод	Путь	Auth	Назначение
GET	`/health/`	AllowAny	Health-check
GET	`/ops/ttm/`	AllowAny	Серверные TTM-маркеры
POST	`/ops/ttm/mark/`	AllowAny	Запись TTM-маркера (CI/CD)
GET	`/csrf/`	AllowAny	Подготовка CSRF-cookie сценария
POST	`/register/`	AllowAny	Регистрация пользователя
POST	`/login/`	AllowAny	Аутентификация и выдача token
POST	`/logout/`	IsAuthenticated	Инвалидация токена и сессии
GET	`/profile/`	Проверка внутри view	Профиль текущего пользователя

3. Контракты endpoint-ов¶

`POST /api/register/`¶

Request:

username (required)
email (required, unique)
password (required, validate_password)
password_confirm (required)
first_name, last_name (optional)

Response 201:

message
user
token

Ошибки:

400 при mismatch паролей.
400 при дубликате username/email.
400 при нарушении password policy.

`POST /api/login/`¶

Request:

username, password

Response 200:

message
user
token

Ошибки:

400 пустой body.
400 неверные учетные данные.
400 отключенный пользователь.

`POST /api/logout/`¶

Побочные эффекты:

удаление DRF token пользователя;
session.flush().

4. Модель данных¶

`auth_app.User`¶

Базируется на AbstractUser.
Дополнительные поля:
email unique
created_at
updated_at
Таблица: auth_user.

5. Безопасность¶

Поддерживаются Token и Session auth.
В REST_FRAMEWORK default permission задан как AllowAny; доступ ограничивается на уровне view.
Для production требуется убрать дефолтные значения SECRET_KEY, DEBUG.

6. Операционные заметки¶

Команда контейнера: migrate + gunicorn.
Внешний порт по Compose: 8001.
Основные env: DATABASE_URL, SECRET_KEY, DEBUG, fallback DB_*.

7. Диаграмма сценария auth¶

sequenceDiagram
  participant C as Client
  participant A as auth_service

  C->>A: POST /api/register
  A-->>C: 201 user + token
  C->>A: POST /api/login
  A-->>C: 200 user + token
  C->>A: GET /api/profile (Authorization)
  A-->>C: 200 profile
  C->>A: POST /api/logout
  A-->>C: 200 logout successful

8. Известные ограничения¶

GET /api/profile/ декларирован как AllowAny, но вручную возвращает 401 при неаутентифицированном запросе.
Формат ошибок между endpoint-ами не полностью унифицирован.

9. Дополнительная детализация внутренних функций (append-only)¶

Ниже перечислены прикладные функции, реализующие бизнес-логику сервиса (кроме стандартного framework boilerplate).

9.1 `auth_app.views._issue_token(user)`¶

Источник: auth_service/auth_app/views.py
Назначение: получить или создать DRF token для пользователя.
Вход:
user: экземпляр auth_app.User.
Выход:
строка token key.
Side effects:
запись в таблицу токенов при первом вызове.
Ошибки и edge-cases:
ошибки ORM/БД не перехватываются локально и поднимаются выше.

9.2 `auth_app.views.register(request)`¶

Источник: auth_service/auth_app/views.py
Назначение: регистрация и немедленная выдача токена.
Вход:
JSON body: username, email, password, password_confirm, опционально first_name, last_name.
Выход:
201: message, user, token.
400: message, errors.
Side effects:
создание пользователя;
валидация пароля через Django password validators;
выпуск токена через _issue_token.
Ошибки и edge-cases:
mismatch password/password_confirm;
дубликаты username/email;
неуспех валидации сложности пароля.

9.3 `auth_app.views.login_view(request)`¶

Источник: auth_service/auth_app/views.py
Назначение: проверка credentials и выдача token.
Вход:
JSON body: username, password.
Выход:
200: message, user, token;
400: комбинация error/errors/message (в зависимости от причины).
Side effects:
не создает сессию вручную, работает через serializer-валидацию и token flow.
Ошибки и edge-cases:
пустой body;
неверные credentials;
disabled user;
формат ошибок частично зависит от структуры serializer errors.

9.4 `auth_app.views.user_profile(request)`¶

Источник: auth_service/auth_app/views.py
Назначение: вернуть профиль текущего пользователя.
Вход:
request.user.
Выход:
200 с данными UserSerializer;
401 если пользователь не аутентифицирован.
Side effects:
отсутствуют (read-only endpoint).

9.5 `auth_app.views.logout_view(request)`¶

Источник: auth_service/auth_app/views.py
Назначение: завершить доступ пользователя.
Вход:
аутентифицированный запрос.
Выход:
200 с сообщением об успешном logout.
Side effects:
удаление всех token пользователя;
session.flush().

9.6 Контракты сериализаторов как функциональные контракты¶

`UserRegistrationSerializer.validate(attrs)` / `create(validated_data)`¶

Источник: auth_service/auth_app/serializers.py
Вход:
attrs с полями регистрации.
Выход:
validated attrs;
созданный User.
Особенности:
password_confirm используется только на этапе валидации и удаляется перед созданием.

`UserLoginSerializer.validate(attrs)`¶

Источник: auth_service/auth_app/serializers.py
Вход:
username, password.
Выход:
attrs, дополненные user после успешной аутентификации.
Ошибки:
ValidationError при пустых полях, неверных credentials, неактивном пользователе.

10. Соответствие master-документации¶

Источник верхнего уровня: Master-документация проекта.

Контроль	Требование	Проверка	Артефакт
API contract sync	Любое изменение auth endpoint синхронизировано с docs	ревью `register/login/logout/profile` контрактов	PR + docs diff
Security policy	Явная auth-политика и коды ошибок	негативные сценарии auth/access	тесты + API error catalog
Delivery quality	Изменение сервиса не нарушает CI и MkDocs strict	прогон CI и docs build	pipeline/build logs
Risk handling	Известные ограничения зафиксированы	секция ограничений актуальна	сервисная страница

auth_service¶

1. Назначение¶

2. API-каталог¶

3. Контракты endpoint-ов¶

POST /api/register/¶

POST /api/login/¶

POST /api/logout/¶