Как дать права в 1с 7
Обновлено: 04.07.2024
Система прав доступа позволяет описывать наборы прав, соответствующие должностям пользователей или виду деятельности. Структура прав определяется конкретным прикладным решением.
Кроме этого, для объектов, хранящихся в базе данных (справочники, документы, регистры и т. д.) могут быть определены права доступа к отдельным полям и записям. Например, пользователь может оперировать документами (накладными, счетами и т. д.) определенных контрагентов и не иметь доступа к аналогичным документам других контрагентов.
Для реализации ограничения прав доступа в прикладных решениях предназначены специальные объекты конфигурации — Роли. Подробнее.
Интерактивные и основные права
Все права, поддерживаемые системой «1С:Предприятие 8», можно разделить на две большие группы: основные и интерактивные. Основные права описывают действия, выполняемые над элементами данных системы или над всей системой в целом, и проверяются всегда, независимо от способа обращения к данным. Интерактивные права описывают действия, которые могут быть выполнены пользователем интерактивно. Соответственно проверяются они только при выполнении интерактивных операций стандартными способами, причем в клиент-серверном варианте все проверки прав (кроме интерактивных) выполняются на сервере.
Основные и интерактивные права взаимосвязаны. Например, существует основное право Удаление, которому соответствуют два интерактивных права: Интерактивное удаление и Интерактивное удаление помеченных. Если пользователю запрещено Удаление, то и все интерактивные «удаления» также будут запрещены для него. В то же время, если пользователю разрешено Интерактивное удаление помеченных, это значит, что Удаление ему также разрешается.
Кроме того, основные права могут зависеть друг от друга. В результате образуются довольно сложные цепочки взаимосвязей, которые отслеживаются системой автоматически: как только разработчик снимает разрешение на какое-либо право, система сама снимает разрешения на все права, которые зависят от этого права. И наоборот, при установке какого-либо права разработчиком, система сама устанавливает все права, от которых это право зависит.
Например, для того, чтобы пользователь имел право Итерактивное удаление помеченных, ему необходимо обладать интерактивными правом Редактирование. Это право, в свою очередь, требует наличия интерактивного права Просмотр.
Право Интерактивное удаление помеченных требует наличия основного права Удаление. Интерактивное право Редактирование требует наличия основного права Изменение. Интерактивное право Просмотр требует наличия основного права Чтение.
Кроме этого основные права Изменение и Удаление требуют наличия основного права Чтение.
Ограничение доступа к данным на уровне записей и полей
Среди действий над объектами, хранящимися в базе данных (справочниками, документами и т. д.), есть действия, отвечающие за чтение или изменение информации, хранящейся в базе данных. К таким действиям относятся:- чтение — получение записей или их фрагментов из таблицы базы данных;
- добавление — добавление новых записей без изменения существующих;
- изменение — изменение существующих записей;
- удаление — удаление некоторых записей без внесения изменений в оставшиеся.
Для этих действий в процессе настройки ролей могут быть заданы дополнительные условия на данные (ограничение доступа к данным). В этом случае над конкретным объектом, хранимым в базе данных, может быть выполнено запрошенное действие только в том случае, если ограничение доступа к данным для данных этого объекта принимает значение «истина». Аналогичные условия могут быть заданы и для таблиц базы данных, не имеющих объектной природы (регистров).
Для объектных таблиц и регистров сведений могут быть заданы разные ограничения для различных полей таблицы, что позволяет определять ограничения не только на уровне записей базы данных, но и на уровне отдельных ее полей:
Для регистров накопления, бухгалтерского учета и расчета условия позволяют разграничить доступ по значениям измерений (для регистров бухгалтерского учета по балансовым измерениям), а для объектных данных и регистров сведений условия позволяют разграничивать доступ к данным по любым полям.
Условия ограничения можно ввести вручную или создать с помощью конструктора ограничений доступа к данным.
Параметры сеанса
Параметры сеанса представляют собой объекты прикладного решения, которые предназначены для использования в ограничениях доступа к данным для текущего сеанса (но могут применяться и для других целей). Их значения сохраняются в течение данного сеанса «1С:Предприятия 8». Использование параметров сеанса позволяет снизить время доступа к данным при ограничении доступа на уровне записей и полей. Подробнее.
Выполнение на сервере без проверки прав
Привилегированные модули
Существует возможность назначения привилегированных модулей. В такие модули могут быть перенесены операции, использующие данные, на которые у текущего пользователя нет прав.
Например, пользователю могут быть назначены права, позволяющие создавать новый документ. Однако никаких прав на регистр, в котором этот документ создает движения при проведении, пользователю не дано. В такой ситуации процедура проведения документа может быть вынесена в привилегированный модуль, который выполняется на сервере без проверки прав. В результате, несмотря на то, что соответствующий регистр для пользователя недоступен, пользователь все же сможет проводить созданные им документы.
Привилегированный режим исполнения программного кода
Привилегированный режим исполнения кода, аналогичный режиму работы кода привилегированных модулей, можно включить/выключить средствами встроенного языка. Для этого в глобальном контексте предусмотрена процедура УстановитьПривилегированныйРежим (), а также функция ПривилегированныйРежим (), которая позволяет определить, включен привилегированный режим, или нет.
Использование привилегированного режима позволяет, во-первых, ускорить работу, так как не будут накладываться ограничения на доступ к данным, а во-вторых, позволяет выполнять операции с данными от лица пользователей, которым эти данные недоступны.
Привилегированный режим рекомендуется использовать тогда, когда с логической точки зрения нужно отключить проверку прав, или когда можно отключить проверку прав, чтобы ускорить работу. Допустимо использовать привилегированный режим тогда, когда работа с данными от лица некоторого пользователя не нарушает установленные для этого пользователя права доступа.
Настройка прав доступа - одна из самых распространенных задач для разработчиков 1С. Это не значит, что подобные задачи всегда ставятся явно. Большая часть из них связаны с текущей разработкой, ведь новый функционал требует ограничений на использование среди пользователей. Но есть и исключения, когда поступает заказ / задача по ограничению доступа к некоторым данным или функциям в информационной базе.
Очень часто можно столкнуться с ситуацией, когда после "горячего" внедрения новой системы у большого количества пользователей имеются полные права. То есть пользователей с возможностями администратора информационной базы слишком много. Как результат - множество ошибок в данных, коллизии в настройках учета, странное поведение системы и непредсказуемые результаты отчетов. Великолепно, не правда ли?
Есть и другие истории, когда с правами все в порядке. Есть толковый администратор, который следит за корректностью их настройки. И все работает какое-то время, пока в дело не вступают разработчики (штатные или с аутсорсинга, не важно!). Множество задач, множество требований, множество ошибок с правами. Такова печальная картина.
Конечно, я дал немного пессимистичную оценку, чтобы подготовить Вас к незабываемому путешествию по типичным ошибкам разработки прав доступа. Мы пройдемся по самым частым проблемам, с которыми приходилось сталкиваться. Это не полный список, поэтому Ваши истории также приветствуются в комментариях.
Обычный процесс разработки
Прежде чем перейти непосредственно к ошибкам, давайте вспомним обычный процесс разработки прав доступа. Все основные настройки доступа выполняются с помощью ролей. Роли - объекты конфигурации, занимающие центральное место в построении модели этих самых прав. Именно с их помощью разработчик может настроить доступ к объектам конфигурации. Они же применяются для более гибкой настройки с помощью разграничений на уровне записей (RLS).
Именно с помощью ролей можно добиться приемлемого результата в части разграничений доступа, но не всегда. Если стандартных возможностей этого объекта недостаточно, то в дело вступают различные дополнительные функции, которые добавляют сами разработчики: регистры дополнительных прав, различные запреты с помощью подписок на события и многое, многое другое.
Поскольку мы говорим о самых частых ошибках, то упор будет делаться именно на роли, т.к. именно они являются самым универсальным и простым решениям для большинства задач по правам.
Внезапные проблемы
Итак, поехали! Какие же ошибки могут быть с правами доступа при разработке?
Просто новый объект
Представьте, что к Вам поступил заказ от клиента: создать новый документ в системе для внесения некоторого пакета документов. Другими словами, нужно добавить документ, который хранит ссылки на другие документы и т.д. Задача ясна. День разработки, после демонстрация клиенту (проверял сам директор!) и можно выкладывать в рабочую систему. Перед обновлением сделаны рассылки, что новый функционал заработает с такого-то числа. Наступает день "икс", Вы вечером обновляете базу и с чувством выполненного долга уходите на сон.
Но утром Вас ждет сюрприз! Никто, кроме директора и системного администратора (да, да! он там главный по 1С) не могут получить доступ к новому документу. В интерфейсе его просто нет!
Догадались в чем дело? Ну, конечно! Новый документ добавлен, функционал отлично разработан, но права на него никто не предоставил.
Следовать лозунгу: "Добавил объект - проверь права!".
А еще лучше - написать Unit-тест, который будет проверять объекты без прав доступа. Посмотрите в сторону
Давать права с разумным подходом.
В типовых конфигурациях давно есть разграничения по профилям доступа, группам доступа. С их помощью можно настраивать права быстро и эффективно.
При добавлении новых объектов не стоит делать ставку на роль "Полные права". Нужно либо добавлять новый объект в существующие роли, либо добавлять новые роли. Все же очевидно.
Скроем подсистему
Пришла срочная задача - нужно части пользователей скрыть подсистему "Супер подсистема увеличения продаж".
Проблема в том, что конфигурация наполнена legacy-кодом, а роли конфигурации не имеют четких ограничений между подсистемами. Все связано как какое-то спагетти. А сделать надо еще вчера (ну, Вы понимаете)!
Выпив 3 кружки кофе, решение приходит само. Нужно лишь скрыть всем ролям доступ к этой подсистеме. Именно подсистеме как объекту конфигурации, а все входящие в ее состав объекты вообще не трогать. Только не забыть дать доступ к этой подсистеме для нужной роли (ее даже можно создать отдельно ради такого случая). Гениально!
Есть еще другой путь - доступ на подсистему не менять, а изменить видимость по умолчанию в настройках.
Это будет работать. У вас даже могут принять работу, и Вы разойдетесь с заказчиком рукопожатием. НО! Вы сделаете не разграничение прав доступа, а лишь измените видимость элементов интерфейса. Да, в первом случае доступа к объекту подсистемы не будет, но к объектам из его состава - пожалуйста! Например, в подсистеме был документ "СекрентныйДокумент". Вы идете вот сюда, нажимаете "Перейти по навигационной ссылке" и вводите примерно такую строку.
Имя документа должно быть таким же как в конфигураторе, тогда все сработает. Все! Список документов, доступ к которым нам ограничили, мы открыли. А дальше работаем как нам нужно.
Вариант с настройкой видимости подсистемы еще проще: заходим в настройки интерфейса и включаем видимость для нужной подсистемы.
Как оказалось, права доступа мы и не настроили.
Для того, чтобы не столкнуться с такой ситуацией достаточно запомнить, что настройки видимости подсистем и настройки видимости на объекты подсистемы - это не права доступа. Это лишь ограничения / настройки интерфейса. А ограничивать доступ к данным с помощью интерфейса - это последнее дело при разработке.
Реквизит больше недоступен
Иногда можно столкнуться с задачей - запретить некоторым пользователям просматривать / изменять определенный реквизит у объекта. В ролях можно настраивать "доступ" к отдельным реквизитам.
"Это так круто!", можно услышать от некоторых разработчиков. Действительно, поставил нужные чек боксы и вперед - задача решена!
Вот только есть один нюанс - к правам доступа эти возможности не имеют никакого отношения. Как и в прошлом примере, все это интерфейсные настройки. Например, если ограничить доступ к реквизиту с помощью роли, то прочитать его все равно будет можно с помощью обычных запросов.
А если данные таким способом можно прочитать, то о каком разграничении доступа может идти речь.
Не используйте эти настройки для решения задач с правами доступа. Это интерфейсные функции.
Для разграничения доступа на изменение реквизитов Вы можете использовать проверки заполнения, события объектов (перед записью, при записи, обработка проведения и др.), в которых реализуете проверки программно. Запретить же просмотр отдельных реквизитов объекта эффективно практически невозможно. Только если дорабатывать все возможные формы, отчеты и другие места конфигурации, добавляя проверки на доступ к нему. Но вот сопровождать такое я бы не взялся.
Есть другой эффективный способ - вынести реквизит в отдельную таблицу и настраивать доступ на нее. Но это уже совсем другая история.
Видимость команд
Выше мы настраивали видимость подсистем. Как уже было сказано, решать так задачи с правами смысла нет, т.к. права на самом деле и не изменяются. По такому же принципу часто поступают не с подсистемами целиком, а с отдельными командами или объектами.
Как и в прошлый раз, по умолчанию пользователь не будет видеть команды в интерфейсе. Но что ему мешает сделать так.
Фиаско? Еще какое!
Повторюсь: настройка видимости и настройка прав доступа - совершенно разные вещи. Никогда не пытайтесь решить вопросы прав доступа с помощью настроек интерфейса.
Новая роль
Выстроенная ролевая модель, четкое разграничение прав доступа. грамотно настроенный RLS! Ваша система эталон работы с правами. И оно понятно, ведь информация в ней чувствительная, ведь это отдел казначейских операций. Сотрудники одного отдела не должны видеть операции соседних подразделений и наоборот. В общем, безопасность на высшем уровне!
Но вот однажды, выпуская новую задачу в рабочую базу, что-то пошло не так! После обновления ВСЕ пользователи стали видеть все заявки, хотя изменения в существующие правила RLS никто не вносил. Что же произошло?
Как Вы догадались - была добавлена новая роль. Нет нет, роль имеет настройки доступа только для тех объектов, для которых действительно нужно. В том числе и для объектов с той самой чувствительной информацией. Вот только есть одна проблема: при добавлении новой роли никто в ней не описал правила RLS, в итоге он перестал работать для всех кому эту роль добавили (в нашем примере ее, допустим, добавили большинству сотрудников).
Как известно, пользователь получает максимальный доступ, который ему предоставляют роли. В нашем случае роль без RLS дает больше прав, чем остальные. Вот платформа их и применяет.
Как же такое вообще можно предотвратить?
Вообще, если в системе есть RLS, то это дополнительная ответственность для разработчиков:
- Нужно корректно писать запросы
- Необходимо учитывать это в отчетах
- При добавлении ролей нужно добавлять правила RLS (это как раз наш случай)
- Некоторый код не будет работать с RLS совсем (например, некоторые приемы с объектной техникой работы с данными, или вложенные подзапросы большой глубины и т.д.).
- И др.
Так что тут можно посоветовать быть более внимательным и писать Unit-тесты для проверки прав доступа.
RLS не наша тема
Информация выше Вас напугала и теперь использовать RLS никогда не будете? Есть способ проще! Можно в динамических списках, отчетах и других местах подбора данных программно устанавливать отборы на получаемую информацию. Например, добавить ограничения по организации. Вот такой код в событии "При создании на сервере" решает эту задачу.
И ведь все работает! Но раз уж этот подход попал в статью, значит не все так гладко. Проблема в том, что ограничения доступа к данным здесь нет, есть только интерфейсные ограничения. Этот подход еще можно назвать как "костыльный RLS". Его обычно применяют, когда задачу надо сделать еще месяц назад, а в ИТ-отдел уже ломятся сотрудники с требованием ограничить доступ.
Проблема в том, что есть множество других путей получить доступ к этим данным. Предусмотреть все возможные ограничения с помощью программных "костылей" невозможно. Например, пользователь вывел отчет, а в него попал "запретный" документ. Ничто не мешает нам его открыть. Слышу вопрос: "Так в форме документа тоже можно сделать программную проверку при открытии!?". Конечно можно! Но что мне мешает в отчете вывести интересующие меня данные из документа с помощью СКД.
Все защиты пали! А как жаль, ведь потрачены десятки часов работы.
И опять, все это интерфейсные настройки. Зачем заниматься этим, если нужно ограничивать права доступа?
Сроки горят? Отлично, "костыль" оправдан! Только не забудьте вернуться к этому вопросу в будущем.
Я сам настрою
И на последок еще один небольшой "фейл". Иногда в системе имеется дополнительный функционал настройки доступа. Например, регистр сведений "Дополнительные права", в котором каждому пользователю добавляются отдельные функции.
Не раз приходилось сталкиваться с такой ситуацией, что права все настраиваются и все работает. Гибкие настройки - мечта администратора и все такое. Но.
У пользователей тоже есть доступ к этому регистру! Причем у всех и на изменение. Да, этот регистр может быть не выведен явно в интерфейс, но это не гарантия того, что любопытные коллеги будут исследовать информационную систему и найдут эту пасхалку. А раз так, то выдать им себе дополнительные права не составит проблем.
Вывод простой: создавая инструменты управления доступом, не забудьте разграничить доступ на этот инструмент.
На самом деле
Это далеко не полный список потенциальных ошибок. Скорее это самые простые, распространенные и банальные ситуации. Возможно, Вы уже знакомы с некоторыми из них. Какие-то допускали Ваши коллеги, какие-то коллеги коллег, но точно не Вы!
Скажу Вам по секрету, только никому не рассказывайте: за все время работы с платформой 1С и решениями на ее основе автором были сделаны все перечисленные ошибки. И даже больше!
Но если бы не было ошибок, то и опыта бы не было. А также этой публикации :)
Читайте также: