Перейти к содержанию

Нет доступа к форме или ошибка авторизации — Решение проблем

Runbook помогает разобрать обращения, когда пользователь не может открыть форму задачи или получает ошибку авторизации. Здесь собраны признаки инцидента, логика проверки доступа, чек-лист диагностики и SQL-запросы для быстрой проверки прав. Для инженеров поддержки и администраторов.

1. Когда использовать и сопоставление симптомов

Сценарий подходит, если есть один из следующих признаков инцидента:

  1. Пользователь видит Нет доступа к задаче или переходит на /error/403.
  2. Открытие задачи по ID не работает, хотя задача существует.
  3. Запросы к data source/форме возвращают 403 Forbidden.
  4. Есть жалобы на «ошибка авторизации» после логина/refresh токена.

Сопоставьте симптом с наиболее вероятной причиной и тем, что проверить в первую очередь:

Симптом Вероятная причина Что проверить первым
После логина сразу 401/403 недействительный access/refresh-токен, истекла сессия auth/token-v2, auth/token/refresh, auth/info
Нет доступа к задаче при прямом открытии ID задача есть, но CheckTaskAccess=false tasks/check-exist-and-access/{taskId}
Только часть пользователей не открывает задачу role/subscriber различия UserTaskPermissions, подписка на задачу
Доступ к задаче есть, но source возвращает 403 нет прав на конкретный data source endpoint source + серверный AccessDeniedException
Через замещение доступ пропал на конкретных задачах задача конфиденциальная признак confidential + проверка access без замещения

2. Как устроена проверка доступа

2.1 Контур аутентификации и проверка доступа к задаче

Последовательность запросов при входе и проверке сессии:

  1. SPA получает токен через POST /api/auth/token-v2.
  2. Обновление сессии: POST /api/auth/token/refresh.
  3. Проверка текущей сессии: GET /api/auth/info.
  4. Глобально 403 перехватывается интерсептором и обычно ведёт на /error/403 (кроме URL из списка исключений).

Перед открытием формы фронтенд проверяет доступ к задаче:

  1. SPA вызывает GET /api/tasks/check-exist-and-access/{taskId}.
  2. Сервер возвращает:
  3. IsTaskExists,
  4. IsUserHasAccess,
  5. TaskShortInfo.
  6. При IsTaskExists = true и IsUserHasAccess = false фронтенд показывает сообщение «нет доступа» с владельцем и исполнителями задачи.

2.2 Как рассчитывается доступ к задаче и data source

Доступ к задаче проверяется по следующей логике:

  1. Проверяется существование задачи.
  2. Системный робот (SystemRobot) — доступ всегда есть.
  3. Уволенный пользователь (IsFired) — доступа нет.
  4. Для административных операций (удаление задачи, доступ к data source):
  5. либо полный доступ (super-admin),
  6. либо право на изменение задачи (Set).
  7. Для обычного открытия задачи:
  8. подписка на задачу даёт доступ,
  9. для конфиденциальной задачи доступ через замещение не расширяется,
  10. затем проверка через функции БД fn_UserTaskPermissions / fn_CheckUserTaskPermissions.

Запрос к data source при отказе в доступе возвращает 403. Это отдельный уровень прав: пользователь может иметь базовый доступ к задаче, но не иметь доступа к конкретному source или действию.

3. Что смотреть при разборе (чек-лист)

При разборе инцидента пройдите по шагам:

  1. Зафиксировать: userId, taskId, URL экрана, время, текст ошибки.
  2. Проверить аутентификацию:
  3. успешен ли auth/token-v2 или auth/token/refresh,
  4. возвращает ли auth/info корректного пользователя.
  5. Проверить tasks/check-exist-and-access/{taskId}:
  6. IsTaskExists = false — это не доступ, а отсутствующая или некорректная задача,
  7. IsTaskExists = true, IsUserHasAccess = false — чистый случай прав.
  8. Если это 403 от data source:
  9. зафиксировать конкретный endpoint source,
  10. разделить проблему прав задачи и прав source.
  11. Проверить, не уволен ли пользователь, нет ли эффекта перевоплощения (impersonation).
  12. Проверить, не конфиденциальная ли задача (для таких задач замещение ограничено).
  13. Проверить факт подписки пользователя на задачу.
  14. Проверить fn_UserTaskPermissions/fn_CheckUserTaskPermissions по задаче.

4. SQL и материалы для поддержки

Следующие SQL-запросы позволяют проверить права доступа пользователя к задаче напрямую в базе данных: наличие пользователя, доступность задачи через денормализованный контур прав, проверку через функцию и факт подписки.

-- Входные параметры
-- @user_id int
-- @task_id int

-- Базовая информация по пользователю
select
        u.UserID,
        u.IsFired
from dbo.Users u
where u.UserID = @user_id;

-- Базовая информация по задаче
select
        t.TaskID,
        t.SubcatID,
        t.UserID as OwnerUserID
from dbo.Tasks t
where t.TaskID = @task_id;

-- Видит ли пользователь задачу через денормализованный контур прав
select top (1)
        utp.TaskID,
        utp.UserID
from dbo.UserTaskPermissions utp
where utp.TaskID = @task_id and
      utp.UserID = @user_id;

-- Проверка права через функцию (MS SQL путь)
select
        p.TaskID
from dbo.fn_CheckUserTaskPermissions(
        @task_id,
        @user_id,
        (
            select t.SubcatID
            from dbo.Tasks t
            where t.TaskID = @task_id
        )
) p;

-- Проверка подписки на задачу
select top (20)
        ms.TaskID,
        ms.UserID,
        ms.DateAdd
from dbo.MailSubscribers ms
where ms.TaskID = @task_id and
      ms.UserID = @user_id
order by
        ms.DateAdd desc;

Если разобраться не удалось, соберите и приложите к обращению в поддержку 1Ф:

  1. userId, taskId, URL и шаги воспроизведения.
  2. Ответы auth/info и tasks/check-exist-and-access/{taskId}.
  3. Текст или скриншот 403 (если от data source — какой именно endpoint).
  4. SQL-снимок из блока выше.
  5. Было ли перевоплощение (impersonate) и повторяется ли проблема без него.