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

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

Этот сценарий помогает разобрать обращения, когда пользователь не может открыть форму задачи или получает ошибку авторизации. Здесь собраны признаки инцидента, логика проверки доступа, чек-лист диагностики и 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 (кроме allowlist 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) и повторяется ли проблема без него.