Тестирование прав доступа к объектам с помощью xddTestRunner / Vanessa-ADD

30.01.23

Разработка - Тестирование QA

Проверка прав доступа пользователей к объектам информационной базы с помощью xddTestRunner / Vanessa-ADD.

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
(только для физ. лиц)
Тестирование прав доступа к объектам с помощью xddTestRunner / Vanessa-ADD:
.7z 9,72Kb
4 1 850 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

- Скажите я имею право?
- Да, имеете.
- А я могу?..
- Нет, не можете.

Посвящается всем тем, кто хоть раз в жизни собирал вручную изменённые RLS при обновлении конфигурации...

Тестировалось на конфигурации Бухгалтерия Предприятия 3.0.127.49.

Одна из основных задач при настройке прав доступа - это обеспечить, чтобы какие-то пользователи видели какие-то данные, а другие их не видели. Например, чтобы пользователи головной организации видели все документы, а пользователи филиала - только документы филиала. Решаются эти задачи с помощью назначения соответствующих ролей и настройки RLS. Проблема же заключается в том, что рано или поздно вся эта грамотно настроенная и доказавшая свою состоятельность на практике система прав доступа, мягко говоря, идёт к коту под хвост. Причины могут быть самые различные. Но, пожалуй, самая частая связана с обновлением конфигураций. Где-то в правах что-то добавилось типовое, где-то что перетёрлось нетиповое - и всё, начинается "ужас-ужас! тот кто не надо увидел то, что не надо!". Разумеется, грамотное проектирование доработок конфигурации значительно уменьшает подобные риски (а иногда и вовсе их исключает), но в любом случае, перед установкой новой конфигурации на рабочий сервер, обычно хочется убедиться, что права "не съехали".

Сразу оговорюсь, предлагаемый тут вариант - это не универсальное средство, а всего лишь ещё один дополнительный эшелон для защиты от ошибки.

Итак, приступим. Будем решать следующую упрощённую (но при этом вполне реальную) задачу: в организации применяется политика, согласно которой пользователи головной организации должны иметь полный доступ ко всем документам, а пользователи филиала - только доступ к документам филиала. Нам нужно проверить выполняется ли эта политика на практике. 

Предлагаемый вариант решения такой: раз нужно проверить выполняется ли на практике, значит и проверять будем тоже на практике. Т.е. возьмём какого-нибудь пользователя головной организации (с достаточными правами, но без полных прав; например, это может быть ГБ или зам.ГБ), и попробуем под ним прочитать/записать/создать документы и головной организации, и филиала. И это должно у него получиться. А потом возьмём пользователя филиала, и попробуем под ним прочитать/записать/создать документы филиала (это у него должно получиться!), а также прочитать/записать/создать документы головной организации (а это не должно у него получиться!).

 
 Полный код модуля обработки тестирования

 

Как театр начинается с вешалки, так и файл тестов xddTestRunner начинается с процедуры ЗаполнитьНаборТестов(). В ней мы определяем, что наш тестовый пользователь с именем "ПользовательГоловной" принадлежит к головной организации, а тестовый пользователь "ПользовательФилиала" - к филиалу. Далее перебираем все документы в метаданных, пропускаем те из них, которые начинаются с "Удалить", и создаём тесты. В параметрах теста передаем имя проверяемой таблицы (например, "Документ.СчетНаОплатуПокупателю"), вид проверяемых прав ("чтение"/"запись"/"создание") и фильтр для отбора какого-то конкретного документа для проверки есть к нему доступ у пользователя или нет (в нашем случае это будет фильтр по Организации).

У данного файла-теста есть всего два метода:

  • Процедура ТестДолжен_ПроверитьЕстьДоступ() - для проверки что у пользователя есть доступ к объектам с указанным видом прав
  • и Процедура ТестДолжен_ПроверитьНетДоступа() - для проверки, что у пользователя нет доступа.

Методы тривиальны. На входе получают параметры теста (см. выше), а внутри с помощью вызова функции ПолучитьСсылкуНаОбъект() получают ссылку на какой-нибудь объект информационной базы и через процедуры ПроверитьЕстьДоступКДанным()/ПроверитьНетДоступаКДанным() проверяют есть ли у пользователя доступ к этому объекту.

Функция ПолучитьСсылкуНаОбъект() тоже весьма незамысловата. Она возвращает первую попавшуюся ссылку на объект БД из таблицы, переданной в параметре ИмяТаблицы (например, "Документ.СчетНаОплатуПокупателю") и с отборами, переданными в структуре Фильтр (в текущей версии функции работают только сравнения на равенство). 

Единственный момент, над которым пришлось задуматься - это использовать или не использовать в функции ПолучитьСсылкуНаОбъект() в запросе ключевое слово "РАЗРЕШЕННЫЕ". В текущем варианте решил не использовать. Дело в том, что если использовать "РАЗРЕШЕННЫЕ", то в процедуре ТестДолжен_ПроверитьЕстьДоступ() при вызове

СсылкаНаОбъект = ПолучитьСсылкуНаОбъект(ИмяТаблицы, Фильтр);

вернётся пустое значение. Как-будто в базе нет объектов такого типа. Хотя на самом деле они могут там быть, просто у пользователя нет к ним доступа. Решил, что всё-так не буду писать "РАЗРЕШЕННЫЕ". В связи с этим в методе ТестДолжен_ПроверитьНетДоступа() вызов функции ПолучитьСсылкуНаОбъект() пришлось обернуть в Попытка ... Исключение (т.к. запрос без слова "РАЗРЕШЕННЫЕ" генерирует исключение "Нет прав доступа" в случае, если у пользователя нет прав на чтение данных из БД):

	Попытка
		СсылкаНаОбъект = ПолучитьСсылкуНаОбъект(ИмяТаблицы, Фильтр);
	Исключение
		// всё ок, не смогли получить
	    Возврат;
	КонецПопытки;

Вообще, я исхожу из того, что пусть лучше будут ложноположительные срабатывания, чем ложноотрицательные. Пусть лучше тест покажет, что есть ошибка там, где её на самом деле нет, чем покажет, что ошибки нет там, где она на самом деле есть.

Ну и, наконец, сами процедуры проверки наличия или отсутствия прав доступа к конкретному объекту БД:

  • Проверка наличия доступа на чтение осуществляется через вызов ПолучитьОбъект() для ссылки на объект БД.
  • Проверка наличия доступа на запись осуществляется через ПолучитьОбъект() + Записать().
  • Проверка наличия доступа на создание нового осуществляется через копирование существующего объекта, ситуативного дозаполнения (например, установки даты документа) и записи. 
Процедура ПроверитьЕстьДоступКДанным(СсылкаНаОбъект, ВидПрав)

	Если ВидПрав = "чтение" Тогда
		ОбъектБД = СсылкаНаОбъект.ПолучитьОбъект();
	ИначеЕсли ВидПрав = "запись" Тогда
		ОбъектБД = СсылкаНаОбъект.ПолучитьОбъект();
		ОбъектБД.Записать();
	ИначеЕсли ВидПрав = "создание" Тогда
		НовыйОбъект = СсылкаНаОбъект.Скопировать();
		Если Метаданные.Документы.Содержит(НовыйОбъект.Метаданные()) Тогда
			НовыйОбъект.Дата = ТекущаяДатаСеанса(); //у некоторых документов почему-то не заполняется автоматически дата, поэтому заполним её явно
		КонецЕсли;
		НовыйОбъект.Записать();
	КонецЕсли;

КонецПроцедуры

Проверка на отсутствие доступа сделана через "инверсию" проверки на наличие доступа. Т.е. вызываем процедуру ПроверитьЕстьДоступКДанным() и смотрим. Если было вызвано исключение, считаем, что это случилось из-за того, что у пользователя нет прав доступа. Если же исключения не было, значит ПроверитьЕстьДоступКДанным() отработала без ошибок и у пользователя есть доступ к данным.

Процедура ПроверитьНетДоступаКДанным(СсылкаНаОбъект, ВидПрав);
	
	БылоИсключение = Ложь;
	
	Попытка
		ПроверитьЕстьДоступКДанным(СсылкаНаОбъект, ВидПрав);
	Исключение
	    БылоИсключение = Истина;
	КонецПопытки;
	
	Если НЕ БылоИсключение Тогда
		ВызватьИсключение "У пользователя есть права на """ + ВидПрав + """, хотя их быть не должно!";
	КонецЕсли;
	
КонецПроцедуры

Про файл теста вроде бы и всё.

 

Теперь про методику тестирования.

Этап 1. Подготавливаем пользователя головной организации (в нашем примере, это пользователь с именем "ПользовательГоловной", но рекомендуется проверять под каким-то реальным пользователем!), заходим под ним в базу, запускаем тест в xddTestRunner, анализируем результаты.

Этап 2. Подготавливаем пользователя филиала, заходим под ним в базу (в нашем примере, это пользователь с именем "ПользовательФилиала", но рекомендуется проверять под каким-то реальным пользователем!), заходим под ним в базу, запускаем тест в xddTestRunner, анализируем результаты.

Как видите, тут тоже без неожиданностей и пасхалочек. Единственный момент, который надо прояснить - это как "подготовить пользователя". Дело в том, что для корректной работы xddTestRunner и этого теста необходимо учесть определённые моменты, такие как:

  • наличие у пользователей ролей Администрирование (не путать с "полными правами"!) и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок - иначе xddTestRunner просто не запустится,
  • отключение у пользователя предупреждений об опасных действиях,
  • отключение у пользователя доменной аутентификации и установка ему известного вам пароля,
  • перенос/отключение даты запрета редактирования для этого пользователя,
  • обновление нумерации объектов (да-да! чтобы не получилось так, что запустили тест, прождали полчаса-час пока он выполняется, а в конце увидели протокол, в котором написано, что значительная часть тестов упала, потому что "не удалось записать, т.к. номер объекта не уникальный"),
  • и т.п.

Справиться со всем этим (точнее, почти со всем) поможет обработка, на форме которой есть реквизиты Логин (тип = строка), Пароль (тип = строка), ИмяТестовогоСервера (тип = строка; нужна чтобы случайно не запустить на рабочем сервере!), УстановитьПароль (тип = булево; признак нужно или не нужно устанавливать пароль для пользователя), ОбновитьНумерацию (тип = булево; признак нужно или нет обновлять нумерацию объектов), и вызывающая следующую функцию:

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

Запускать это нужно, разумеется, под администратором.

Вот теперь совсем всё. Весь приведённый исходный код доступен под лицензией Mozilla Public Licence 2.0 (для совместимости с проектом Vanessa-ADD).

Ну и, конечно, пользуясь случаем, хочу ещё раз выразить благодарность всем разработчикам Vanessa-ADD. Отличный инструмент, выручает регулярно. Спасибо!

Вступайте в нашу телеграмм-группу Инфостарт

См. также

Тестирование QA DevOps и автоматизация разработки Программист Пользователь 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.178.26.

2160 руб.

20.01.2022    9716    36    0    

18

DevOps и автоматизация разработки Тестирование QA Программист Пользователь 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.230.

3360 руб.

05.08.2024    2971    18    1    

12

Тестирование QA Программист Бесплатно (free)

Статья о практическом опыте внедрения unit-тестирования в legacy-конфигурацию 1С (УКФ) с использованием фреймворка YAxUnit. Автор делится возникшими техническими вызовами и организационными сложностями, а также их решениями, которые включают использование модулей-помощников, макетов и контекста. Приводятся реальные примеры тестирования HTTP-сервисов и событий документов.

25.07.2025    670    batsy66    5    

9

Тестирование QA Бесплатно (free)

В статье расскажем, как Sentry помогает компании Magnit Tech эффективно решать задачи оперативного выявления и анализа ошибок. Поделимся практическим опытом внедрения Sentry и объясним, почему этот инструмент превосходит другие бесплатные аналоги по функционалу и удобству использования. Рассмотрим гибкий механизм настройки оповещений об ошибках журнала регистрации, который позволяет адаптировать уведомления под конкретные нужды проектов. Объясним, как Sentry используется для мониторинга производительности базы 1С, обеспечивая стабильность работы критически важных систем. Затронем тему интеграции Sentry с системами мониторинга инфраструктуры и CDN.

17.07.2025    893    daniloffartur    1    

6

Тестирование QA Бесплатно (free)

YAxUnit – это сравнительно молодой, но амбициозный и быстро развивающийся инструмент из мира open-source. Расскажем о ключевых этапах развития инструмента и особенностях работы над open-source проектом.

17.07.2025    2145    Жолтокнижниг    1    

22

HighLoad оптимизация Тестирование QA Системный администратор Программист Бесплатно (free)

В мире 1С импортозамещение используемых программных продуктов в первую очередь касается миграции СУБД с MSSQL на Postgres. Одна из основных проблем перехода — более «слабый» оптимизатор запросов Postgres по сравнению с MSSQL, когда запросы на MSSQL выполнялись значительно быстрее, чем на Postgres. Автор статьи разработал инструмент, который позволяет без значительных затрат выявить эти «проблемные» запросы. Основная идея подхода: конвертация на Postgres запросов, снятых при использовании MSSQL, и сравнение времени выполнения на MSSQL и на Postgres.

10.07.2025    1370    berserg    4    

9

Тестирование QA Программист Бесплатно (free)

Процесс тестирования в команде автора эволюционировал от ручных проверок до полноценной автоматизации с использованием современных инструментов и контейнеризации. Начав с Vanessa-ADD в качестве основного решения, команда постепенно расширила стек, включив в него Vanessa-Automation для UI-тестирования, YAxUnit для модульных проверок, Coverage41C для анализа покрытия кода, а также Gitlab CI, Allure и SonarQube для мониторинга качества и непрерывной интеграции. Статья объясняет, почему в качестве стартового инструмента была выбрана Vanessa-ADD и как удалось организовать запуск дымовых и сценарных тестов в CI-контуре на Windows-сервере. Рассмотрен вопрос анализа покрытия кода тестами: зачем потребовался подсчет и какими сложности сопровождали настройку Coverage41C в клиент-серверной архитектуре. Также автор рассказывает про переход на Docker (рассматривался готовый образ, но в итоге был создан собственный) и смену инфраструктуры с Windows и PowerShell на Linux и Bash.

27.06.2025    2167    TaGolovkina    3    

22

Тестирование QA Бесплатно (free)

Ведущий разработчик Инфостарт Лаборатории рассказал о том, с какими сложностями сталкиваются команды разработки 1С, внедряющие у себя процессы автоматизации тестирования и о подходах и конкретных решениях, которые помогают эти проблемы обойти. Доклад прозвучал на конференции «Стачка» в Ульяновске в апреле 2025 года и был ориентирован на руководителей и тимлидов команд разработки и тестирования, а также на действующих тестировщиков.

20.06.2025    4236    kuntashov    5    

38
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. RustIG 1887 30.01.23 09:40 Сейчас в теме
(0) 1. Способ применяется не только при использовании тестовых программ, но и при обычной отладке кода - пишется внешняя обработка, которая запускает создание/изменение/чтение/удаление/проведение любого справочника/документа/регистра/др.объектов.
Я в свое время делал глобальную доработку видимости по подразделениям и запускал универсально: бежал по объектам метаданных документов: открывал список документов...

2. Права доступа - это ведь не только права на чтение/изменение/и т.д., но настройка видимости/доступности записей/полей/списков/и т.д. - чтобы, например, не видеть в журнале документов "объект не найден". Кто-то скажет, что это РЛС-настройка, я же скажу, что это больше чем РЛС. Тут еще надо прописывать логику видимости/доступности для разных условий/сценариев.
3. q_i 585 30.01.23 11:33 Сейчас в теме
1. Ну вот - теперь такая обработка не только написана, но ещё и в общем доступе. )) В ней можно задать любую свою логику контроля прав в ЗаполнитьНаборТестов(), т.е. прописать там какому пользователю что можно, а что нельзя, и после этого подёргать за ТестДолжен_ПроверитьЕстьДоступ()/ТестДолжен_ПроверитьНетДоступа().
2. Согласен, что тема значительно шире, чем она раскрыта в данной публикации. Но нельзя объять необъятное, поэтому я взялся за то, что, как мне кажется, нужно проконтролировать в первую очередь. В конце концов, если выбирать между вариантом, что пользователь увидит "объект не найден" и вариантом, что он увидит сам объект во всём своём великолепии, то очевидно, что второй вариант куда более неприятен и чреват негативными последствиями.
2. artbear 1570 30.01.23 10:34 Сейчас в теме
(0) Полезное применение Vanessa-ADD.
Борьба с правами - это боль!
Уже есть несколько дымовых тестов из Ванесса-АДД, которые также проверяют права, но их недостаточно и тесты из статьи явно будут полезны!

И от лица разработчиков Vanessa-ADD спасибо за его использование и публикацию статьи с примерами использования!
4. siamagic 17.02.23 07:09 Сейчас в теме
(2)Вы точно программист? Эта задача для студентов, делается на коленке, никакие фрейморвки левые тут не нужны.
Оставьте свое сообщение