Аудит Leadera — полный отчёт

Аудит проекта Leadera

Дата: 30.03.2026
Версия: pre-production, миграции 1–5

1. Обзор проекта

Leadera — SaaS-система управления IT-ландшафтом с диаграммами Ганта.

Стек

Доменная модель

User ──┬── Space (через space_members с role)
        │
        └── GanttChart (принадлежит Space)
              ├── GanttSection
              └── GanttTask

Роли: admin, editor, viewer — назначаются на уровне Space через таблицу space_members.

Что реализовано (endpoints)

Auth (5): register, login, refresh, change-password, logout
Spaces (9): CRUD + members CRUD
Gantt Charts (9): CRUD + archive + members (добавлен, но удалён в миграции 5)
Gantt Sections (5): CRUD + reorder
Gantt Tasks (4): CRUD

Итого: ~32 endpoint

2. Архитектура и качество кода

2.1. Backend — структура

cmd/server/main.go        — точка входа
internal/
  domain/                  — модели (User, Space, GanttChart, etc.)
  dto/                     — request/response DTO (auth, space, gantt)
  handlers/                — HTTP handlers (auth, space, gantt)
  middleware/              — auth, cors, space, gantt, role, logging, recovery
  repository/              — слой доступа к данным
  service/                 — бизнес-логика
  config/                  — конфигурация (.env)
  utils/                   — jwt, password, response, validation
migrations/                — SQL миграции (1-5)

Оценка: ✅ Чистая layered архитектура. Разделение ответственности чёткое.

2.2. Frontend — структура

src/app/
  core/auth/               — auth service, interceptor
  core/models/             — app.model, space.model
  core/services/           — space.service, space-storage.service
  pages/auth/              — sign-in, sign-up, reset-pw, etc.
  pages/gantt/             — компоненты, модалки, сервисы, модели
  pages/dashboards/        — spaces list, dashboard
  layouts/                 — navbar, topbar, main-layout

Оценка: ✅ Стандартная Angular-структура. Signals для state management.

2.3. Проблемы кода

3. Права доступа — главный вопрос

3.1. Текущая реализация

Права назначаются исключительно через Space:

1. Таблица space_members — связка user ↔ space с role (admin/editor/viewer)
2. SpaceMiddleware.RequireSpace() — проверяет членство и записывает ContextSpaceRole в context
3. RoleMiddleware.RequireMinRole() — проверяет иерархию ролей (admin > editor > viewer)

Диаграммы Ганта НЕ имеют собственной системы ролей. Таблица gantt_chart_members была создана (миграция 4) и тут же удалена (миграция 5). Все проверки доступа к диаграммам идут через space membership.

3.2. Как это работает

Запрос → AuthMiddleware (JWT → userID)
       → SpaceMiddleware.RequireSpace() (проверяет space_members → ContextSpaceRole)
       → GanttMiddleware.RequireGanttChart() (проверяет chart.space_id == spaceID)
       → RoleMiddleware.RequireMinRole("editor") (проверяет ContextSpaceRole)

Это правильно. Любой член Space с ролью editor+ может создавать/редактировать диаграммы. Viewers — только читать.

3.3. 🔴 Критическая проблема: Frontend не соответствует Backend

Frontend MembersModalComponent пытается управлять участниками диаграммы:

• ganttService.addMember(chartId, dto) → /api/v1/spaces/{spaceId}/gantt-charts/{chartId}/members
• ganttService.updateMemberRole(chartId, userId, dto) → .../members/{userId}
• ganttService.removeMember(chartId, userId) → .../members/{userId}

Backend GanttHandler.RegisterRoutes() НЕ регистрирует маршруты для members диаграмм. После удаления gantt_chart_members (миграция 5) эти endpoints не существуют.

Результат: модальное окно «Участники диаграммы» на фронтенде не работает — все вызовы вернут 404.

3.4. 🔴 Проблема: Role fallback

В role_middleware.go:28-31:

role := c.GetString(ContextSpaceRole)
if role == "" {
    role = c.GetString(ContextRole) // fallback на глобальную роль User
}

Если ContextSpaceRole не установлен, используется глобальная роль пользователя (из JWT). Это значит:

• Пользователь с role=admin в таблице users получит admin-доступ к любому space, даже если он не член этого space
• Но SpaceMiddleware проверяет членство раньше, так что в цепочке RequireSpace() → RequireMinRole() это не эксплуатируется
• Однако если RequireMinRole() используется без RequireSpace() — это дыра

Рекомендация: Удалить fallback на ContextRole. Если ContextSpaceRole пуст — отказывать.

3.5. Рекомендации по правам доступа

1. Удалить модалку участников диаграммы на фронтенде — она мертва
2. Или добавить раздел «Участники Space» с возможностью управления ролями через /spaces/:space_id/members (эти endpoints работают)
3. Удалить fallback на ContextRole в role_middleware.go
4. Добавить проверку: editor не может повысить кого-то до admin (сейчас может — AddMember разрешает editor+ назначать любую роль)

4. Безопасность

4.1. Критические

4.2. Высокие

4.3. Средние

5. Инфраструктура

5.1. Текущее состояние

5.2. Проблемы

6. Функциональная оценка

6.1. Что работает

6.2. Что НЕ работает или отсутствует

6.3. Оценка готовности

Система на стадии каркаса. Backend API функционален для CRUD операций, но:

• Визуализация Ганта — основная фича — не реализована (нет canvas/SVG рендеринга)
• Управление участниками только на уровне Space
• Нет CI/CD, тестов, мониторинга

7. Приоритизированный план исправлений

Неделя 1 — Критическое (безопасность)

Неделя 2 — Архитектура прав

Неделя 3 — Функциональность

8. Резюме

Ключевые выводы

1. Права доступа — архитектурно верно: роль назначается через Space, не через диаграмму. Но фронтенд ещё не обновлён после удаления gantt_chart_members.
2. Безопасность — критические уязвимости в конфигурации (JWT secret, CORS, bcrypt). Требуют немедленного исправления до любого публичного деплоя.
3. Функциональность — CRUD работает, но основная ценность (визуализация Ганта) не реализована.
4. Код — чистый, хорошая архитектура, но есть мёртвый код и незарегистрированные маршруты.

Общая оценка: 🔴 Pre-alpha

Проект готов к внутренней демонстрации CRUD, но не готов к продакшену. Первоочередное — безопасность и исправление мёртвых endpoints.