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

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

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

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

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

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

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 из списка исключений).

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

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

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

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

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

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

2.4 Доступ к data source

Запрос к 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. Симптом → вероятная причина → проверка

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

Симптом Вероятная причина Что проверить первым
После логина сразу 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 без замещения

5. 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;

6. Что приложить при обращении в поддержку

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

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