Авторизация, объектный доступ и состояние

Кто вы и что вам разрешено

Аутентификация устанавливает субъект запроса; авторизация определяет, может ли этот субъект выполнить действие с конкретным объектом. В лаборатории токены публичные и фиксированные, чтобы управлять ролью без настоящих аккаунтов. Это учебный механизм, который нельзя переносить в production. Ошибка 401 относится к отсутствию или неверности токена, но действующий пользователь тоже может получить 403 или скрывающий 404.

Проверяйте не только роль, но и отношение к объекту: автор, другой участник той же команды, editor, другая команда. Для t1 Вера имеет право публикации как editor north, но не чтения чужого draft. Борис не имеет ни права чтения draft, ни права публикации. Олег editor, однако его команда south исключает доступ к объекту north раньше проверки роли. Один «admin-подобный» пользователь не представляет всю матрицу.

Порядок проверок — отдельная часть оракула

A5 намеренно фиксирует последовательность. Если Борис публикует t2, где он не автор и задача уже published, ответ 403 FORBIDDEN возникает раньше проверки состояния. Под Анной тот же t2 даст 409 ALREADY_PUBLISHED. Это не противоречие: различаются субъекты и первая нарушенная предпосылка. Негативный тест состояния должен иметь достаточные права, иначе 403 маскирует нужную ветвь.

Для пробельного t3 Анна проходит проверки сессии, команды, права и draft, поэтому получает 422 BLANK_TITLE. Если обратиться к t3 без токена, будет 401, а не 422. Запишите это в таблицу решений, затем выполните изолированные примеры каждой ветви. Не предполагайте универсальную семантику «403 всегда раньше 404» для всех сервисов: это точная договорённость нашего контракта.

Последовательность проверяет реальное изменение

Успешная публикация t1 под Верой должна изменить только state исходного объекта, сохранив ID, автора, команду, title, description и priority. Проверьте снимки целиком, затем чтение под Борисом: теперь published становится ему доступен. Повторная публикация под Анной возвращает 409 и не меняет запись. Так одна последовательность связывает действие с изменением поведения чтения, а не ограничивается статусом первой команды.

Каждый независимый сценарий начинает с известного reset. Внутри сценария reset между первым и повторным publish недопустим: он уничтожит нужное состояние и превратит повтор в первую публикацию. Если сценарии идут параллельно по одному t1, они могут мешать друг другу. Для учебного набора выполняйте их последовательно или создавайте отдельные объекты. В реальном наборе планируйте владение данными, безопасную очистку и независимость, иначе случайное падение будет ошибочно принято за дефект прав.

Матрица на свежем t1