Ограничения за достъп до данни в роли 1s. Права за достъп до SCP. RLS. Обща информация и настройки. Ограничете достъпа на ниво запис

Всички настройки на потребителските права, които ще направим в рамките на тази статия, се намират в раздел 1C 8.3 „Администриране“ - „Настройки на потребител и права“. Този алгоритъм е подобен в повечето конфигурации на управлявани формуляри. Програмата 1C Accounting ще бъде използвана като пример, но настройката на правата в други програми (1C UT 11, 1C ZUP 3, 1C ERP) се извършва по абсолютно същия начин.

Нека отидем в секцията „Потребители“ на прозореца с настройки. Тук виждаме две хипервръзки: „Потребители“ и „Настройки за влизане“. Първият от тях ви позволява да отидете директно до списъка с потребители на тази информационна база. Преди да създадете нов потребител, разгледайте възможните настройки за влизане (хипервръзка вдясно).

В тази форма за настройки можете да зададете сложността на паролата (минимум 7 знака, задължително съдържание от различни видове знаци и т.н.). Тук можете също да посочите дължината на паролата, нейния период на валидност и забраната за достъп до програмата за потребители, които не са имали активност за определен период от време.

Сега можете да преминете директно към добавяне на нов потребител към 1C. Можете да направите това, като щракнете върху бутона "Създаване", както е показано на изображението по-долу.

Първо, посочваме пълното име - „Антонов Дмитрий Петрович“ и избираме физическо лице от съответната директория. Тук можете да посочите и отдела, в който работи наш служител.

Името за вход "AntonovDP" беше заменено автоматично като съкращение на пълното име "Antonov Dmitry Petrovich". Задайте парола и удостоверяване за 1C Enterprise. Тук можете също да посочите дали този потребител има право сам да променя паролата.

Да предположим, че искаме Дмитрий Петрович Антонов да бъде наличен в списъка за избор при стартиране на тази информационна база. За да направите това, трябва да зададете флага на елемента "Покажи в списъка за избор". В резултат на това прозорецът за оторизация при стартиране на програмата ще изглежда като този, показан на фигурата по-долу.

Нека обърнем внимание на друга важна настройка в картата с ръководството за потребителя - „Входът в програмата е разрешен“. Ако забавянето не е зададено, тогава потребителят просто няма да може да влезе в тази информационна база.

Права за достъп

След попълване на всички данни в потребителската карта - Антонов Дмитрий Петрович, ние ще ги запишем и ще преминем към настройка на правата за достъп, както е показано на фигурата по-долу.

Пред нас се отвори списък с предварително въведени в програмата профили за достъп. Поставете отметки в квадратчетата, които са задължителни.

Достъп до групови профили

Профилите на групата за достъп могат да бъдат конфигурирани от основната форма за настройка на потребители и права. Отидете в секцията „Групи за достъп“ и щракнете върху хипервръзката „Профили на групи за достъп“.

Нека създадем нова група от отворената форма за списък. В табличния раздел на раздела „Разрешени действия (роли)“ е необходимо да поставите отметки в квадратчетата за онези роли, които ще повлияят на правата за достъп на потребителите, включени в групата, която създаваме. Всички тези роли се създават и конфигурират в конфигуратора. Те не могат да бъдат модифицирани или създадени от потребителски режим. Можете да избирате само от съществуващ списък.

RLS: Ограничение за достъп на ниво запис

Позволява ви по-гъвкаво да конфигурирате достъпа до програмни данни в определени секции. За да го активирате, задайте флага на елемента със същото име във формата за настройки на потребителя и правата.

Моля, обърнете внимание, че активирането на тази настройка може да повлияе неблагоприятно на производителността на системата. Въпросът е, че механизмът RLS променя всички заявки в зависимост от зададените ограничения.

Нека отидем на профила на групата за достъп „Тестова група“, който създадохме по-рано. Фигурата по-долу показва, че след активиране на ограничението за достъп на ниво запис се появи допълнителен раздел „Ограничения за достъп“.

Да предположим, че искаме потребителите, на които е назначена тестовата група, да имат достъп до данни за всички организации в тази информационна база, с изключение на посочените в профила.

В горната таблична секция задайте ограничението за достъп по организация. В долната част ще поясним, че няма да се предоставя достъп до данни (документи, директории и др.) за организацията Roga LLC.

Често има нужда от частично ограничаване на достъпа до данни. Например, когато потребител трябва да види документи само за своята организация. В такива случаи 1C използва механизъм за ограничаване на достъпа на ниво запис (т.нар. RLS - Record Level Securiy).

Да предположим например, че сме изправени пред следната задача. Предприятието поддържа многофирмено счетоводство и всеки контрагент и потребител на база данни принадлежи към определена организация. Необходимо е да се осигури достъп до директорията „Изпълнители“ по такъв начин, че всеки потребител да може да преглежда, редактира и добавя контрагенти само към своята организация.

За да разрешим проблема, ще използваме платформата „1C:Enterprise 8.2″. Нека създадем нова конфигурация, в свойствата на която опцията "Управлявано приложение" ще бъде избрана като основен режим на стартиране.

След това ще създадем директорията „Организации“ и още две директории - „Изпълнители“ и „Потребители“ с атрибут „Организация“. В допълнение към директориите се нуждаем от два параметъра на сесията - „Организация“ и „Потребител“ (от съответните типове). Стойностите на тези параметри се задават в началото на конфигурационната сесия и се съхраняват до нейния край. Това са стойностите на тези параметри, които ще използваме, когато добавяме условия за ограничаване на достъпа на ниво запис.

Параметрите на сесията се задават в специален модул - “Модул за сесия”

В този модул ние описваме предварително дефинираната процедура „SetSessionParameters“, в която извикваме функцията на предварително подготвения общ модул „FullPermissions“. Това се налага поради особеностите на работата на базата данни в режим на управлявано приложение, когато част от програмния код може да се изпълни само от страна на сървъра (няма да се спирам на обяснението на тези принципи в тази статия).

Код 1C v 8.x Процедура Задаване на параметри на сесия (задължителни параметри)
FullPermissions.SetSessionParameters();
EndProcedure

В свойствата на модула “FullPermissions” поставете отметки в квадратчетата “Server”, “Server call” и “Privileged” (последното означава, че процедурите и функциите на този модул ще се изпълняват без контрол на достъпа). Текстът на модула ще изглежда така:

Код 1C v 8.x Функция DetermineCurrentUser()
CurrentUser = Directories.Users.FindByName(UserName(), True);
Връщане на CurrentUser;
Крайни функции

Процедура SetSessionParameters() Експортиране
CurrentUser = Определяне на CurrentUser();
CurrentOrganization = Directories.Organizations.EmptyReference();
Ако ValueFilled(CurrentUser) Тогава
CurrentOrganization = CurrentUser.Organization;
EndIf;
SessionParameters.User = CurrentUser;
SessionParameters.Organization = CurrentOrganization;
EndProcedure

FunctionSessionParameterSet(ParameterName) Експортиране
Върната стойност, попълнена (Параметри на сесия [Име на параметър]);
Крайни функции

Функция RoleAvailableToUser(RoleName) Export
Връща RoleAvailable(RoleName);
Крайни функции

В модула на управляваното приложение ще проверим за присъствието на потребител на конфигурация в директорията „Потребители“ (за по-лесно ще го търсим по име) и ще изключим системата, ако не бъде намерен. Това е необходимо, за да се гарантира, че параметрите на сесията са попълнени.

Код 1C v 8.x Процедура за предсистемна работа (неизправност)
// всички освен администратора ще бъдат проверени за присъствие в директорията "Потребители".
Ако не е FullPermissions.RoleAvailableToUser("FullPermissions"), тогава
Ако НЕ FullPermissions.SessionParameterSet("Потребител") Тогава
Предупреждение ("Потребител """ + Потребителско име() + """ не е намерен в директорията!");
Отхвърляне = вярно;
Връщане;
EndIf;
EndIf;
EndProcedure

Сега можем да преминем директно към описанието на ограниченията за достъп. За да направите това, създайте ролята „Потребител“ и отидете в раздела „Шаблони за ограничаване“, където добавяме нов шаблон „AccountsReadingChange“ със следния текст на шаблона: WHERE Организация = Организация #Параметър(1)

Текстът на шаблона за ограничение е разширение на езика за заявки. За разлика от обикновената заявка, текстът на ограничението трябва задължително да съдържа клаузата „WHERE“. Като стойности на параметрите на заявката (в нашия случай това е „&Организация“) се използват стойностите на параметрите на сесията със същото име. Конструкция на формата #Параметър(1) означава, че системата ще замени текста, подаден като първи параметър на мястото, където се използва шаблонът на това място. С помощта на дадения шаблон ще се проверява всеки запис от таблицата (в нашия случай това ще бъде справка "Изпълнители"). За записи, чиято стойност на атрибут „Организация“ съвпада с посочената в съответния параметър на сесията, условието, описано в шаблона, ще бъде изпълнено. Така тези записи ще бъдат достъпни за четене, редактиране или добавяне (в зависимост от това за кое от тези права се отнася шаблонът). Ще демонстрирам горното с нашия пример.

Нека да отидем в раздела „Права“ на ролята „Потребител“ и да отворим списъка с права в директорията „Акаунти“. Ще използваме шаблона за ограничение „AccountsReadChange“ за разрешенията „Четене“, „Промяна“ и „Добавяне“.

За правото „Четене“ ще използваме шаблон с параметъра „OR ThisGroup“. В същото време потребителите на тази роля ще могат да четат не само елементите на директорията „Акаунти“ на тяхната организация, но и всички групи от тази директория.

#AccountsReadingChange("ИЛИ ThisGroup")

Тъй като при добавяне на нови елементи на директорията, системата извършва имплицитно четене на предварително зададени атрибути (това е необходимо, например, за номериране), е необходимо да се осигури безпрепятствено четене на тези полета. За да направите това, добавете допълнителен ред с празен текст на ограничение към таблицата с ограничения за достъп до данни и избройте полетата, за които се прилага това правило - Връзка, Версия на данните, Родител, Код.

Така се решава задачата за ограничаване на достъпа на ниво запис. Потребителите със съществуващи ограничения ще имат достъп да преглеждат и редактират данни само за тяхната организация.

Платформата 1C:Enterprise 8 има вграден механизъм за ограничаване на достъпа до данни на ниво запис. Можете да прочетете обща информация за него тук. Накратко, RLS ще ви позволи да ограничите достъпа до данни според някои условия за стойностите на полетата. Например, можете да ограничите достъпа на потребителите до документи в зависимост от стойността на атрибута "Организация". Някои потребители ще работят с документи за организацията "Управляващо дружество", а останалите с организацията "Млекопреработвателно предприятие". Като пример.

Подготовка

Примерът е реализиран в демонстрационната конфигурация на SCP 1.3. Нека създадем потребител "Storekeeper" и да добавим ролята "Storekeeper" със същото име към него.

Сега нека да продължим директно към настройката на правата за достъп на ниво запис. Нека преминем към интерфейса „Администриране на потребители“. В главното меню изберете "Достъп на ниво записи -> Опции". Тук поставяме отметка в квадратчето „Ограничаване на достъпа на ниво запис по типове обекти“ и в списъка с обекти изберете „Организации“.

По този начин ние активирахме използването на RLS. Сега трябва да го настроите.

Контролът на достъпа на ниво запис не се конфигурира отделно за всеки потребител или профил на разрешение. RLS е конфигуриран за потребителски групи. Нека добавим нова потребителска група, нека я наречем "Storekeepers"

Съставът на групата от дясната страна на формуляра показва списък на потребителите, принадлежащи към тази група. Нека добавим потребителя, който създадохме по-рано. Отляво има таблица с ограничения за достъп. В настройката на RLS сме избрали достъпът да бъде ограничен само от организации, така че виждаме само един тип обект за достъп. Кликнете върху бутона "Настройки за достъп". Отваря се обработката за задаване на разрешения за текущата група.

В списъка с обекти за достъп за групата добавете организацията "PPE "Предприемач"". Ще оставим вида на наследяване на права непроменен. Правото на обекта за достъп ще бъде настроено на четене и запис. Натиснете "OK", настройките са готови. Току-що настроихме RLS на организационно ниво.

Какво вижда потребителят

Стартирайте програмата под създадения преди това потребител и отворете директорията "Организации". Ето как ще изглежда списъкът за нашия потребител и за потребител с пълни права:

Както виждаме, потребителят на storekeeper вижда само една организация, за която сме отворили достъп за четене. Същото важи и за документи, като разписки за стоки и услуги.

По този начин потребителят не само няма да вижда организации, достъпът до които не е зададен за него, но също така няма да може да чете / пише документи и други обекти в информационната база, за които правата в ролята на атрибута "Организация “ са зададени.

Разгледахме най-простия пример за настройка на RLS. В следващата статия ще говорим за внедряването на механизма RLS в конфигурацията "Manufacturing Enterprise Management" версия 1.3.

1C има вградена система за права за достъп (тази система се нарича 1C роли). Тази система е статична - тъй като администраторът е задал правата на 1C, така да бъде.

Освен това има динамична система за права на достъп (наречена - RLS 1C). В него правата на 1C се изчисляват динамично по време на работа на потребителя въз основа на зададените параметри.

Една от най-често срещаните настройки за сигурност в различни програми е набор от разрешения за четене / запис за потребителски групи и след това - включване или изключване на потребител от групи. Например подобна система се използва в Windows AD (Active Directory).

Такава система за сигурност в 1C се нарича Roles 1C. Roles 1C се намира в конфигурацията в клона Общи / Роли. 1C ролите действат като групи, за които са присвоени 1C права. След това потребителят се включва или изключва от тази група.

Като щракнете двукратно върху името на ролята 1C, ще отворите редактора на права за ролята 1C. Отляво има списък с 1C обекти. Изберете произволно и вдясно ще се покажат опции за права за достъп (най-малко: четене, добавяне, промяна, изтриване).

За горния клон (името на текущата конфигурация) са зададени административни права на 1C и достъп до стартиране на различни опции.

Всички права на 1C са разделени на две групи - „просто“ право и същото право с добавяне на „интерактивно“. Какво означава?

Когато потребителят отвори формуляр (например обработка) и натисне бутон върху него, програмата на вградения език 1C извършва определени действия, например изтриване на документи. За разрешението на тези действия (извършвани програмно) - "просто" отговарят правата на 1C.

Когато потребителят отвори дневник и започне да прави нещо от клавиатурата самостоятелно (например въвеждане на нови документи), това са „интерактивни“ 1C права.

Потребителят може да има няколко налични роли, като в този случай разрешенията се добавят заедно.

Разделът за възможностите за задаване на права за достъп с помощта на роли е 1C обект. Тоест можете или да активирате достъпа до директорията, или да го деактивирате. Не може да се включи малко.

За това има разширение на ролевата система 1C, наречено 1C RLS. Това е динамична система от права за достъп, която ви позволява частично да ограничите достъпа. Например, потребителят вижда само документи за определен склад и организация и не вижда останалите.

Внимателно! Когато използвате объркваща схема RLS 1C, различни потребители може да имат въпроси, когато се опитват да проверят един и същ отчет, генериран от различни потребители.

Вземате определена директория (например организации) и определено право (например четене). Разрешавате четене за ролята на 1C. В панела за ограничаване на достъпа до данни задавате текста на заявката, който връща TRUE или FALSE в зависимост от настройките. Настройките обикновено се съхраняват в информационния регистър (например регистър с информация за конфигурацията Accounting UserAccessRightsSettingsUsers).

Тази заявка се изпълнява динамично (когато се опитвате да реализирате четене) за всеки запис в директорията. По този начин, за онези записи, за които заявката за защита е върнала TRUE, потребителят ще ги види, но останалите не.
Правата на 1C, които са предмет на ограничения на RLS 1C, са маркирани в сиво.

Копирането на същите настройки на RLS 1C се извършва с помощта на шаблони. Правите шаблон, наименувате го (например) MyTemplate, посочвате заявка за сигурност в него. След това в настройките за права за достъп до 1C посочете името на шаблона по следния начин: "#MyTemplate".

Когато потребител работи в режим 1C Enterprise, когато RLS 1C работи, той може да получи съобщение за грешка „Недостатъчни права“ (например за четене на директорията Xxx).

Това означава, че RLS 1C блокира четенето на няколко записа.

За да предотвратите появата на такова съобщение, е необходимо да използвате думата ALLOWED () в текста на заявката на вградения език 1C.

Например:

Програмата 1C има вградена система за права за достъп, която се намира в Конфигуратор - Общи - Роли.

Какво характеризира тази система и какво е нейното основно предназначение? Тя ви позволява да опишете набори от права, които съответстват на позициите на потребителите или техните дейности. Тази система от права за достъп е статична по природа, което означава, че тъй като администраторът е задал правата за достъп на 1C, тя е такава. В допълнение към статичната има втора система за права на достъп - динамична (RLS). В тази система правата за достъп се изчисляват динамично, в зависимост от зададените параметри, в процеса на работа.

Роли в 1C

Най-често срещаните настройки за сигурност в различни програми са така нареченият набор от разрешения за четене / запис за различни потребителски групи и в бъдеще: включване или изключване на конкретен потребител от групи. Такава система например се използва в операционната система Windows AD (Active Directory). Системата за сигурност, използвана в софтуера 1C, се нарича роли. Какво е? Ролите в 1C са обект, който се намира в конфигурацията в клона: Общи - Роли. Тези 1C роли са групи, за които са присвоени права. В бъдеще всеки потребител може да бъде включен и изключен от тази група.

Като щракнете двукратно върху името на ролята, ще отворите редактора на правата за ролята. Вляво има списък с обекти, маркирайте някой от тях и вдясно ще видите опции за възможни права за достъп:

— четене: получаване на записи или техни частични фрагменти от таблица на база данни;
- добавяне на: нови записи при поддържане на съществуващи;
— промяна: извършване на промени в съществуващи записи;
- изтриване: някои записи, запазване на останалите непроменени.

Имайте предвид, че всички права за достъп могат да бъдат разделени на две основни групи - това е „просто“ право и такова право с добавяне на „интерактивна“ характеристика. Какво се има предвид тук? А работата е следната.

В случай, че потребителят отвори някаква форма, например обработка, и в същото време щракне върху нея с мишката, програмата на вградения език 1C започва да изпълнява конкретни действия, например изтриване на документи. За разрешаването на такива действия, извършвани от програмата, правата на 1C са отговорни, съответно, "просто".

В случай, че потребителят отвори дневника и започне да въвежда нещо самостоятелно от клавиатурата (например нови документи), тогава "интерактивните" 1C права са отговорни за разрешаването на такива действия. Всеки потребител може да има няколко налични роли наведнъж, след което се добавя разрешението.

RLS в 1C

Можете да разрешите достъпа до директорията (или документа) или да го забраните. Не можете просто да го включите малко. За тази цел има известно разширение на ролевата система 1C, което се нарича RLS. Това е динамична система за права за достъп, която въвежда частични ограничения за достъп. Например, само документи на определена организация и склад стават достъпни за вниманието на потребителя, той не вижда останалите.

Трябва да се има предвид, че системата RLS трябва да се прилага много внимателно, тъй като е доста трудно да се разбере нейната сложна схема и различните потребители могат да имат въпроси, когато например сравняват един и същ отчет, който се генерира от различни потребители. Нека разгледаме такъв пример. Избирате конкретна директория (организации, например) и конкретно право (четене, например), тоест разрешавате четене за ролята на 1C. В същото време задавате текста на заявката в дистанционния панел Data Access Restrictions, според който се задава False или True в зависимост от настройките. Обикновено настройките се съхраняват в специален информационен регистър.

Тази заявка ще се изпълни динамично (когато се направи опит за организиране на четене) за всички записи в директорията. Работи по следния начин: тези записи, за които е зададена заявката за сигурност - Вярно, потребителят ще види, но други не. Правата на 1C с установени ограничения са маркирани в сиво.

Операцията по копиране на идентични RLS настройки се извършва с помощта на шаблони. Като начало създавате шаблон, като го наименувате например MyTemplate, в който отразявате заявката за сигурност. След това в настройките за права за достъп посочете името на този шаблон по следния начин: "#MyTemplate".

Когато потребител работи в режим 1C Enterprise, когато се свързва с RLS, може да се появи съобщение за грешка като: „Недостатъчни права“ (например за четене на директорията XXX). Това показва, че RLS системата е блокирала четенето на някои записи. За да предотвратите появата на това съобщение отново, трябва да въведете думата РАЗРЕШЕНО в текста на заявката.

https://zabor-vam.ru/product/metallicheskie/zabory-iz-profnastila/