Как при приёмке проверить доступ к чужим данным в API
Попросите исполнителя открыть один закрытый документ из двух аккаунтов: сначала из аккаунта владельца, затем по той же ссылке из другой организации. Проверьте отдельно карточку документа и скачивание файла. Если кнопка исчезла, это ещё не значит, что сервер запретил доступ.
Что подготовить
Создайте в тестовой среде две вымышленные организации с ролями «клиент». Документ второй пометьте «Демо-Б». Заранее договоритесь, может ли он публиковаться по ссылке и как должен работать приглашённый гость.
Порядок проверки
Запросите показ без смены файла
Пусть исполнитель откроет документ и скачает его как Б. В другом профиле браузера войдите как А и откройте ранее сохранённые адреса карточки и скачивания. Не используйте реальные файлы клиентов.
Зафиксируйте решение о приёмке
Если А получил содержимое «Демо-Б», запишите конкретный путь и версию сборки и верните сценарий на исправление. Если не работает и законный доступ Б, отметьте проверку как неполную. В отчёте отдельно укажите непроверенные экспорты.
Фрагмент протокола, который можно переслать исполнителю
Б → файл Б: открывается, метка «Демо-Б» видна
А → файл Б: отказ; метка «Демо-Б» отсутствует
Б → карточка: открывается после исправления
Сборка: ____ Исполнитель ретеста: ____Критерий результата и ограничения
Для владельца результат — короткая запись о том, какое именно обещание по изоляции проверено, на какой версии и кто повторит тест. Примите этот пункт после ретеста с обеими ролями.
Что остаётся непроверенным
Временные подписанные ссылки могут намеренно давать доступ предъявителю. Оценивайте срок, возможность выдачи и правила пересылки по согласованным требованиям, а не по одному статусу.
