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