Права наше все
Настройка прав доступа — одна из самых распространенных задач для разработчиков 1С. Это не значит, что подобные задачи всегда ставятся явно. Большая часть из них связаны с текущей разработкой, ведь новый функционал требует ограничений на использование среди пользователей. Но есть и исключения, когда поступает заказ / задача по ограничению доступа к некоторым данным или функциям в информационной базе.
Очень часто можно столкнуться с ситуацией, когда после "горячего" внедрения новой системы у большого количества пользователей имеются полные права. То есть пользователей с возможностями администратора информационной базы слишком много. Как результат — множество ошибок в данных, коллизии в настройках учета, странное поведение системы и непредсказуемые результаты отчетов. Великолепно, не правда ли?
Есть и другие истории, когда с правами все в порядке. Есть толковый администратор, который следит за корректностью их настройки. И все работает какое-то время, пока в дело не вступают разработчики (штатные или с аутсорсинга, не важно!). Множество задач, множество требований, множество ошибок с правами. Такова печальная картина.
Конечно, я дал немного пессимистичную оценку, чтобы подготовить Вас к незабываемому путешествию по
типичным ошибкам разработки прав доступа. Мы пройдемся по самым частым проблемам, с которыми приходилось сталкиваться. Это не полный список, поэтому Ваши истории также приветствуются в комментариях.
Обычный процесс разработки
Прежде чем перейти непосредственно к ошибкам, давайте вспомним обычный процесс разработки прав доступа. Все основные настройки доступа выполняются с помощью ролей. Роли — объекты конфигурации, занимающие центральное место в построении модели этих самых прав. Именно с их помощью разработчик может настроить доступ к объектам конфигурации. Они же применяются для более гибкой настройки с помощью разграничений на уровне записей (RLS).
Именно с помощью ролей можно добиться приемлемого результата в части разграничений доступа, но не всегда. Если стандартных возможностей этого объекта недостаточно, то в дело вступают различные дополнительные функции, которые добавляют сами разработчики: регистры дополнительных прав, различные запреты с помощью подписок на события и многое, многое другое.
Поскольку мы говорим о самых частых ошибках, то упор будет делаться именно на роли, т.к. именно они являются самым универсальным и простым решениям для большинства задач по правам.
Внезапные проблемы
Итак, поехали! Какие же ошибки могут быть с правами доступа при разработке?
Просто новый объект
Представьте, что к Вам поступил
заказ от клиента: создать новый документ в системе для внесения некоторого пакета документов. Другими словами, нужно добавить документ, который хранит ссылки на другие документы и т.д. Задача ясна. День разработки, после демонстрация клиенту (проверял сам директор!) и можно выкладывать в рабочую систему. Перед обновлением сделаны рассылки, что новый функционал заработает с такого-то числа. Наступает день "икс", Вы вечером обновляете базу и с чувством выполненного долга уходите на сон.
Но утром Вас ждет сюрприз! Никто, кроме директора и системного администратора (да, да! он там главный по 1С) не могут получить доступ к новому документу. В интерфейсе его просто нет!
Догадались в чем дело? Ну, конечно! Новый документ добавлен, функционал отлично разработан, но права на него никто не предоставил.
И что же делать?
Дать права и забыть
Вы — разработчик в крутой компании. Разрабатываете целые подсистемы с нуля, оптимизируете производительность, вносите множество изменений в типовой функционал и ругаете коллег из фирмы "1С" какие же они "косячники" после развертывания свежих релизов. Занимаетесь только разработкой, только хардкор! В один прекрасный день выясняется, что консультант / аналитик (нужное подчеркнуть) который работал с бизнес-пользователями, увольняется. А значит часть его обязанностей перейдет на Вас! Какой ужас, придется раздавать права доступа по заявкам. Работа не достойная разработчика!
Но Вы то знаете как быть. Вашей сообразительности нет границ и теперь на каждую заявку прав доступа достаточно выдать полные права. Все новые объекты в конфигурации не требуют никаких настроек, ведь роль "Полные права" автоматически получает к ним доступ. Один раз сделать и никаких повторных обращений. Все довольны, а разработка будет продолжаться дальше. В конце концов, мы все в компании одна большая команда, а значит отношения построены на доверии. Зачем нам какие-то разграничения прав!
Решение рабочее, поспорить трудно. Вот только других проблем создает прилично: изменение данных в закрытом периоде, "едет" отчетность, кто-то изменяет "чувствительные" данные, изменились настройки учетной политики 5 раз за неделю и другие "курьезные" ситуации.
И что, не давать права?
Скроем подсистему
Пришла срочная задача — нужно части пользователей скрыть подсистему "Супер подсистема увеличения продаж".
Проблема в том, что конфигурация наполнена legacy-кодом, а роли конфигурации не имеют четких ограничений между подсистемами. Все связано как какое-то спагетти. А сделать надо еще вчера (ну, Вы понимаете)!
Выпив 3 кружки кофе, решение приходит само. Нужно лишь скрыть всем ролям доступ к этой подсистеме. Именно подсистеме как объекту конфигурации, а все входящие в ее состав объекты вообще не трогать. Только не забыть дать доступ к этой подсистеме для нужной роли (ее даже можно создать отдельно ради такого случая). Гениально!
Есть еще другой путь — доступ на подсистему не менять, а изменить видимость по умолчанию в настройках.
Это будет работать. У вас даже могут принять работу, и Вы разойдетесь с заказчиком рукопожатием. НО! Вы сделаете не разграничение прав доступа, а лишь измените видимость элементов интерфейса. Да, в первом случае доступа к объекту подсистемы не будет, но к объектам из его состава — пожалуйста! Например, в подсистеме был документ "СекрентныйДокумент". Вы идете вот сюда, нажимаете "Перейти по навигационной ссылке" и вводите примерно такую строку.
Имя документа должно быть таким же как в конфигураторе, тогда все сработает. Все! Список документов, доступ к которым нам ограничили, мы открыли. А дальше работаем как нам нужно.
Вариант с настройкой видимости подсистемы еще проще: заходим в настройки интерфейса и включаем видимость для нужной подсистемы.
Как оказалось, права доступа мы и не настроили.
Это не норма
Реквизит больше недоступен
Иногда можно столкнуться с задачей — запретить некоторым пользователям просматривать / изменять определенный реквизит у объекта. В ролях можно настраивать "доступ" к отдельным реквизитам.
"Это так круто!", можно услышать от некоторых разработчиков. Действительно, поставил нужные чек боксы и вперед — задача решена!
Вот только есть один нюанс — к правам доступа эти возможности не имеют никакого отношения. Как и в прошлом примере, все это интерфейсные настройки. Например, если ограничить доступ к реквизиту с помощью роли, то прочитать его все равно будет можно с помощью обычных запросов.
А если данные таким способом можно прочитать, то о каком разграничении доступа может идти речь.
Как же тогда
Видимость команд
Выше мы настраивали видимость подсистем. Как уже было сказано, решать так задачи с правами смысла нет, т.к. права на самом деле и не изменяются. По такому же принципу часто поступают не с подсистемами целиком, а с отдельными командами или объектами.
Как и в прошлый раз, по умолчанию пользователь не будет видеть команды в интерфейсе. Но что ему мешает сделать так.
Фиаско? Еще какое!
Но я всегда этим пользовался
Новая роль
Выстроенная ролевая модель, четкое разграничение прав доступа. грамотно настроенный RLS! Ваша система эталон работы с правами. И оно понятно, ведь информация в ней чувствительная, ведь это отдел казначейских операций. Сотрудники одного отдела не должны видеть операции соседних подразделений и наоборот. В общем, безопасность на высшем уровне!
Но вот однажды, выпуская новую задачу в рабочую базу, что-то пошло не так! После обновления ВСЕ пользователи стали видеть все заявки, хотя изменения в существующие правила RLS никто не вносил. Что же произошло?
Как Вы догадались — была добавлена новая роль. Нет нет, роль имеет настройки доступа только для тех объектов, для которых действительно нужно. В том числе и для объектов с той самой чувствительной информацией. Вот только есть одна проблема: при добавлении новой роли никто в ней не описал правила RLS, в итоге он перестал работать для всех кому эту роль добавили (в нашем примере ее, допустим, добавили большинству сотрудников).
Как известно, пользователь получает максимальный доступ, который ему предоставляют роли. В нашем случае роль без RLS дает больше прав, чем остальные. Вот платформа их и применяет.
Но как же так
RLS не наша тема
Информация выше Вас напугала и теперь использовать RLS никогда не будете? Есть способ проще! Можно в динамических списках, отчетах и других местах подбора данных программно устанавливать отборы на получаемую информацию. Например, добавить ограничения по организации. Вот такой код в событии "При создании на сервере" решает эту задачу.
ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбора(
Список.Отбор,
"Организация",
// Здесь передаем список значений для отбора.
// Предположим, что в примере они хранятся в параметре сеанса
ПараметрыСеанса.СписокОрганизацийПользователя,
ВидСравненияКомпоновкиДанных.ВСписке,
"Обязательный отбор по организации",
Истина,
РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный);
И ведь все работает! Но раз уж этот подход попал в статью, значит не все так гладко. Проблема в том, что ограничения доступа к данным здесь нет, есть только интерфейсные ограничения. Этот подход еще можно назвать как "костыльный RLS". Его обычно применяют, когда задачу надо сделать еще месяц назад, а в ИТ-отдел уже ломятся сотрудники с требованием ограничить доступ.
Проблема в том, что есть множество других путей получить доступ к этим данным. Предусмотреть все возможные ограничения с помощью программных "костылей" невозможно. Например, пользователь вывел отчет, а в него попал "запретный" документ. Ничто не мешает нам его открыть. Слышу вопрос: "Так в форме документа тоже можно сделать программную проверку при открытии!?". Конечно можно! Но что мне мешает в отчете вывести интересующие меня данные из документа с помощью СКД.
Все защиты пали! А как жаль, ведь потрачены десятки часов работы.
Как обычно
Я сам настрою
И на последок еще один небольшой "фейл". Иногда в системе имеется дополнительный функционал настройки доступа. Например, регистр сведений "Дополнительные права", в котором каждому пользователю добавляются отдельные функции.
Не раз приходилось сталкиваться с такой ситуацией, что права все настраиваются и все работает. Гибкие настройки — мечта администратора и все такое. Но…
У пользователей тоже есть доступ к этому регистру! Причем у всех и на изменение. Да, этот регистр может быть не выведен явно в интерфейс, но это не гарантия того, что любопытные коллеги будут исследовать информационную систему и найдут эту пасхалку. А раз так, то выдать им себе дополнительные права не составит проблем.
Доступа на права доступа
На самом деле
Это далеко не полный список потенциальных ошибок. Скорее это самые простые, распространенные и 
банальные ситуации. Возможно, Вы уже знакомы с некоторыми из них. Какие-то допускали Ваши коллеги, какие-то коллеги коллег, но точно не Вы!
Скажу Вам по секрету, только никому не рассказывайте: за все время работы с платформой 1С и решениями на ее основе автором были сделаны все перечисленные ошибки. И даже больше!
Но если бы не было ошибок, то и опыта бы не было. А также этой публикации 🙂
P.S. Поделитесь своими историями. Дайте знать, что автор не один такой "косячник" 🙂
Другие ссылки
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Сколько мы (или я) с этими правами доступа намучились. Семь заказчиков в разных у городах, у каждого свои
порядки изаскоки. Одному дай права, у этого убери, а сделай так, чтобы …, но при условии ….(1) не сыпьте соль на рану 🙂
У меня у самого флэшбэки по этому поводу.
(1) О, дааааааааааа, а как в этом «»помогают«» разработчики Раруса! Есть допустим документ Продажа, и Касса, даем роли право на чтение/редактирование этих документов где РЛСконтрагент и РЛСкасса, все круто все работает. Проходит неделя — ничего не работает. Клиент А купил товар, позвонил главному менеджеру, тот не долго думая принял оплату на свою карту,проверив отправил заказ в сборку, а потом перекинул деньги на карту основного менеджера, отразив это документом. Круто? Круто. Возвращается основной менеджер и не может зайти в документ. Некруто. Догадались почему и какая конфигурация?)))
ещё прикольный фэйл, когда кто-то до тебя поставил флаг «Устанавливать права для новых объектов» у роли. и ты не понимаешь что за фигата происходит с правами на твои новые объекты…
(3) я один раз так знатно зафэкапился. Просто эпик фейл был.
Мне все простили, но осадок у всех остался 🙂
(5) У вас кстати фамилия не от слова permision ? Кому как не вам писать статьи про права )
(6) Access denied! 😀
(4) у меня есть подозрение, но боюсь произносить вслух.
О, это великолепная тема RLS! Автору спасибо, что затронул.
Как вспомню — вздрогну… Метод отгадки причин неполадки — даже на форуме подымал, реально пришлось полдня убить — дать все права и последовательно отключать…
А за инструменты работы с ролями разработчикам руки отрубить по самые ноги… Открыл ERP, посмотрел на 2500 ролей, нажал все роли — пошел курить… Вот и приходится энтузиастам плодить отчёты/обработки по правам различной степени годности.
И про ограничение к реквизитам — ведь тоже ловился на этом — зачем тогда вообще делали?( Наивная вера что всё будет хорошо жестоко разбилась о реалии платформы)
Кстати к ошибкам бы ещё отнёс метод ректального программирования для ограничения чего-либо, через добавление «флаговых» ролей чтобы в коде использовать РольДоступна(), отдельный котел в аду для таких разработчиков (максимум РольДоступна(«Администратор»)).
А на самом деле основная проблема при разработке прав — отсутствие чётко проработанных, продуманных правил и бездумное изменение их «на ходу», когда лавинообразно растёт количество хотелок, потом и появляются «исторически сложившиеся» динозавры и пляски с бубнами над ролью, которую нельзя никому давать и т.д.
А как же костыли с УстановитьПривелигированныйРежим() в серверном модуле и изменение запросов с «Выбрать Разрешенные».
Помимо прав на новые объекты, надо проверять есть ли конфликты со связанными объектами. В документе может быть настроено какое-нибудь автозаполнение с обращением к справочнику или регистру. И если доступ к этому регистру закрыт, то и документ работать не будет, даже если на него полные права будут стоять.
(9)
Эта проблема основная, согласен.
И простирается она далеко за задачи с правами доступа. Почти любое внедрение превращается в такой легасикод со своими историческими решениями.
Потом уже просто боишься это трогать.
(10) +
Такие костыли еще те костыли. Иногда и сам использую. Гордиться нечем)
(11) это уже не совсем типичная ошибка, поэтому не стал рассматривать.
А вы как-нибудь такое до прода выявляете?
(14) Ну я бы не сказал, что выявляю, пользуюсь самым простым. У меня есть тестовый пользователь, на котором я тестирую права, которые потом выдаю другим.
Была задача отредактировать систему прав для бухгалтерии, у всех были админские. Я сделал новый профиль и просто тестировал его на пользователе с этим профилем по основным документам и справочникам.
Все ошибки так конечно не найдешь. Но я здесь использую принцип «лучше дать меньше, чем больше». Потому как лишние права выявить гораздо сложнее, чем отсутствующие.
Ну тут много прелестей. И функциональные опции (я кстати не нашёл при беглом чтении, они упомянуты?), и ПравоДоступа пополам с РольДоступна, и любители давать отдельные права на реквизиты и таб.части, и любители лепить привилегированный где ни попадя…
И конечно, горячо любимая тормозуха РЛС.
По известной мне на момент конца 2017 года инсайдерской информации, если в конфигурации более 8-10 ролей (да-да, ролей), то торможение всей механики лавинообразно нарастает. Не знаю, актуально ли это сейчас.
Автору браво, отличная статья. Только грустная…
(16) про функциональные уж не стал писать, она не совсем типичная. Но такое да, есть к сожалению на практике.
Про RLS упомянул, тут сюрпризов очень много.
Нет нет, грустного ничего нет. Просто реальность 🙂
(17) Не скажи. Треть тупняка, выглядящего как отсутствие доступа либо сокрытие в интерфейсе, в нынешних конфах обусловлена именно функциональными опциями.
Ограничить действие роли до какого-то числа или к примеру третьей пятницы в месяце это конечно перебор. Но вот профиль или хотя бы логин/пароль на вход было бы логично.
В чем причина тормозов на РЛС? Индексы не работают?
Функциональные опции идеологически верное решение в единственном случае — когда на каждого пользователя отдельная база.
Как всё сложно!
Быстрее бы уж 1С выпустил типовые конфигурации с искусственным интеллектом,
чтобы админ сказал голосовому помощнику Борису — хочу у этого юзера такие права,
а у этого вот такие!
И всё стало! 🙂
(20) «все стало» — думаю так и будет :))))
(21)Не, а как там в Ветхом завете:
«И сказал Бог: да будет свет. И стал свет.»
А мы сотворены по Образу и Подобию Божию!
Как говорится, есть куда стремиться к совершенству!
Чтобы сказать железяке — «Да будет» и, чтобы стало! 🙂
(8) Мы должны смело называть его, не бояться имени, как это было раньше. Его имя Лорд Волан-Де-УНФ!!))
(23) вот это поворот! Я думал про другие некоторые отраслевки.
Особо правами не занимался, бывало только ошибку в шаблоне исправлю. Но намедни пришлось, тыкаюсь как котенок. Кстати, может я чего не знаю, как, например, угадать, какая роль ограничивает/не ограничивает права или как побыстрее разобраться с шаблоном ограничений?
(15) при лишних правах никто не пожалуется на какую-то проблему. в итоге — бяка.
при недостаче прав — обязательно кто-то прибежит с воплями, бяка — устраняем!
(16) вот, например:
Этого правового монстра определенно надо переделывать на что то более вменяемое.
Особенно радует как в типовых же решениях криво работают их же решения. Например в УТ зачет аванса в документе реализации от сегодня не сделает, потому что ему надо перезаписать ПКО от прошлой недели.
Дополню её пару нюансов.
Когда добавляете в систему новый объект — проверьте типовую роль ПолныеПрава на наличие у нового объекта права «Удаление» и «Удаление предопределенных». Программисты 1С часто бояться менять типовые объекты, особенно те, которые могут повлиять на их собственные права. В больших компаниях роль ПолныеПрава может быть у большого числа пользователей из руководящего состава, часто они не понимают механизмы работы 1С на уровне программиста 1С. Так что удалить что-то важное они вполне могут без контроля ссылочной целостности или без понимания того, что предопределенный элемент может использоваться где-то в коде для заполнения значения по-умолчанию.
Есть отличие двух ролей ПолныеПрава и Администратора. Несмотря на название первой, есть объекты, которые нельзя ни удалять, ни изменять никому. Это объекты не включенные в разделители. Например справочник классификатора банков, который может быть общий сразу для нескольких ИБ с разными разделителями. Но, у роли Администратора право изменять такие объекты есть (видимо для крайних случаев).
После изменения ролей в конфигурации — обновите вспомогательные данные через обработку, если конфигурация на базе БСП. В противном случае можно потом долго ломать голову почему ограничение не срабатывает. Кроме того, если поменяли права доступа пользователю через редактирование профиля группы доступа — попросите пользователя перезайти в 1С минут через 10. Изменения не всегда применяются сразу, а часть прав устанавливается 1 раз при инициализации параметров сеанса и действует до окончания сеанса.
(26) Вот именно. Хотя бухгалтерия при этом возмущается, но это меньшее из зол.
(25) В бухгалтерии 3.0 есть регистр сведений «ПраваРолей» его можно посмотреть левым соединением со справочником «ПрофилиГруппДоступа» и вы получите единую таблицу всех прав ко всем объектам. Дальше ищете там нужный вам объект. У меня даже есть простенькая обработка на такой случай.
Не забывайте, что некоторым объектам недостаточно даже полных прав, там могут ссылки на другие объекты. В этом отношении неплохо помогает журнал регистрации. Он, в случае ошибки покажет к какому объекту не хватает прав.
Как же не хватает в настройках прав доступа запретительных флагов.
В типовой БП 3.0 почти после каждого обновления появляются регистры, для которых не настроена ни одна роль. И почему то они влияют на доступ к документам, к которым они, вроде, не имеют никакого отношения. Разработчики 1С, как ясно, тестируют конфигурацию только с полными правами. Кроме того, в настроенных в пользовательском режиме профилях некоторое количество ролей помечаются как удаленные в конфигурации.Так что, как ни старайся, Фирма 1С все равно всех «сделает» при обновлении.
Да, RLS — сложная тема, особенно, если что-то перестает работать.
Не так давно столкнулся с проблемой — список расходных накладных после обновления релиза у ряда пользователей стал пустым.
Список накладных выводится с помощью отдельного журнала — реестр документов. В итоге оказалось, что ошибка в стандартном шаблоне ограничения доступа на уровне записей (не правильная обработка составного поля, которое содержит значения видов доступа и групп видов). Пришлось разбираться в работе этого шаблона, который далеко не простой. Чтобы шаблон начал работать «корректно» пришлось добавить дополнительные записи в регистр «Группы значений доступа». Все это на столько не интуитивно и сложно, что потратил пол дня рабочего времени.
Комментарий к разделу «Я сам настрою». Давно пользуюсь такой схемой: добавляю регистр (лучше создать отдельное расширение), в нем прописываю права на отдельный объект отдельному пользователю, далее опять же в расширении в функции «ПередЗаписью» (или в какой-нибудь аналогичной») проверяю права, то есть смотрю: а не поименован ли пользователь в этом регистре. На этот регистр я дала следующие права: Полные, Базовые права БСП, которые есть в каждой роли. Теперь любой пользователь имеет право на чтение этого регистра. Но увидеть сам регистр он может только из «Всех функций», а их сам себе может включить только пользователь с полными правами. Применяю эту схему на Бухгалтерии 3.0. Само собой на конфигурациях под старые платформы это работать не будет: там если есть права, то и долезть можно. Поправьте меня, если я в чем-то ошибаюсь. Если у кого-то есть интерес к этой теме могу выложить это расширение на Инфостарте.
КА2.4, справочник физлиц. У админа форма ФЛ открывается с полем документов (паспортные данные), у менеджера — без документов.
Первая мысль — нехватает прав на чтение документов или ещё что-то логичное. Но нет, оказывается, 1с проверяет в коде у пользователя роль «ДобавлениеИзменениеСотрудников» (даже не физлиц), и открывает менеджеру другую урезанную форму. Как так-то? При чем тут роль доступа к Сотрудникам и справочник физлиц? 1с, не делай так больше!
Или ещё.
Та же конфа. Нужно вывести в форму списка ФЛ реквизит. Делов-то лезем в расширение, перехватываем процедуру «МодификацияКонфигурацииПереопределяемый.ПриСозданииНаСервере» (она ведь для этого и предназначена разработчиками), проверяем в ней форму и выводим программно новую колонку. Делов на 2 минуты. И…. ничего не происходит. 1с не добавила в форму справочника физлиц вызов этой процедуры. Приходится тянуть в расширение всю форму фл и править её программно там.
(9)
В ERP совсем другая парадигма. И она отличнейшая!!! Там вы назначаете для каждого объекта по 2 роли: добавление/изменение и чтение (для отчетов просмотр и т.д.). А затем с кирпичиков собираете профиль группы доступа. Нужно создать роль «администратор склада»? Никаких проблем, добавляем роли на просмотр документов 1, 2, 3 и 5, роли на добавление документов 4 и 8. Вуаля — всё работает. Причем собрать профиль — задаа не программиста, а аналитика или консультанта.
(19)
Для роли — да, а вот для пользователя — норм.
(35)
а кто-то отказывается от ролей в пользу полных прав всем и далее интерфейсное ограничение расширением или еще как-то, причем желательно настройки доступов кому-то передать, чтоб не дергали ИТ отдел?
(40) ужас какой
(41) Security through obscurity. кнопку можно просто спрятать, а не ломать ее механизм, чтоб она не работала для кого-то. это дешево и сердито.
(42) это игра с одним результатом)
(43)странно, но вы плюсанули мои комментарии. дуализм, однако.
(44) я думал это шутка ))))