The “role” configuration object gives a set of rights to operations (actions) over configuration objects.
Role "Full Rights".
This is just a role (not predefined) in which all types of rights to all configuration objects are checked.
What distinguishes it from other roles is the presence of the “Administration” right.
If at least one user is created, the system begins to check for the presence of the “Administration” right - at least one user must have it.
Record-level access restrictions
Row Level Security (RLS) – record-level restriction.
The data access restrictions mechanism allows you to manage access rights not only at the level of metadata objects, but also at the level of database objects. The following objects can be used to restrict access to data:
- roles,
- session parameters,
- functional options,
- privileged shared modules,
- keyword ALLOWED in the query language.
The mechanism is designed to restrict access to metadata object table records based on arbitrary conditions imposed on the values of the row fields of these tables. For example, to see records only for “your” counterparties, organizations, etc.
Technical implementation of access restrictions in 1C
1C generates a request to the DBMS. The server cluster adds a section WHERE to the request, which contains the text of the condition for restricting access via RLS, then this request is sent to the DBMS, the extracted data is returned to the 1C client.
This mechanism will work for any request from the client:
- in reports,
- V dynamic lists and in regular list forms
- in custom queries.
Such an implementation of the mechanism greatly affects performance.
Ways to bypass access restrictions.
In large resource-intensive operations (processing document reposting, for example), part of the code can be moved to privileged modules.
A) Privileged module is a common module with the “Privileged” flag in the properties.
Its peculiarity is that the code in it is executed without any access rights control, including RLS.
B) Also privileged the mode can be turned on for document object modules. This is done in the document properties, flag
- Privileged treatment when conducting
- Privileged mode when canceling a transaction
B) Method SetPrivilegedMode()
System command allows you to make part of the code of any module privileged.
From the next line of code, the privileged execution mode will operate.
It will operate until the line to disable this mode or until the end of the procedure / function
(True);
// any code here will be executed without rights control and RLS
SetPrivilegedMode(Lie ); // or end of procedure / function
The number of times privileged mode is enabled must match the number of times it is disabled. However, if within a procedure or function the privileged mode was turned on (once or more), but was not turned off, then the system will automatically shutdown as many times as there were incomplete turns on in the procedure or function being left
If in a procedure or function calls a method SetPrivilegedMode(False) made more than method calls SetPrivilegedMode(True ), then an exception will be thrown
Function PrivilegedMode() returns True if privileged mode is still enabled, and False if it is completely disabled. This does not analyze the number of privileged mode settings in a particular function.
All called procedures and functions will also be executed in privileged mode.
It is also possible to start a privileged session. This is a session in which privileged mode is established from the very beginning of the system. Moreover, during operation the method PrivilegedMode() will always return True, and the ability to disable privileged mode is not supported. Only a user who has access to the administrative rights(Administration right). You can start a session using the key command line launching the client application UsePrivilegedMode or the infobase connection string parameter prmod .
The question naturally arises: Why then set up access restrictions at all if it can be so easily bypassed?
Safe mode.
Yes, you can write external processing with a privileged execution mode and unload/corrupt data. To prevent this, the system has a global context method
SetSafeMode().
Safe mode, among other things, ignores privileged mode.
It must be set before the program call external treatments or export procedures and functions from their modules.
When performing prohibited operations, an exception is thrown at runtime.
In addition, at the role settings level, you can disable the ability for users to interactively launch external reports and processing.
Setting up access restrictions
RLS can only be configured for rights:
- read (select)
- adding (insert)
- change (update)
- delete
For read operations and deletion, an object residing in the database must comply with data access restrictions.
For the add operation The data access restriction must correspond to the object that is planned to be written to the database.
For change operation the data access restriction must comply with the object both before the change (so that the object is read) and after the change (so that the object is written).
For all other rights there is no such option.
Let's add a new restriction for the “read” right of the “Nomenclature” directory. A list of fields for which you can configure the added restriction will open.
This means that if you try to access checked fields, the restriction will be triggered, but if you try to access unchecked fields, the restriction will not work.
If you select the flag " Other fields", the restriction will be configured for all table fields, except for fields for which restrictions are explicitly set.
*Feature: for rights to add, change, delete:
- The restriction can only be configured for all fields.
- There can be only one restriction.
You can configure several conditions for the “Read” right; they will be combined logical operator"AND".
Not all fields of the main constraint data object may be used in restrictions on the following types of database objects:
- in accumulation registers, access restrictions can only contain measurements of the main object of the restriction;
- in accounting registers, restrictions can only use balance sheet measurements of the main object of the restriction
If, under conditions of limited access to the data of the circulating accumulation register, measurements that are not included in the totals are used, then when accessing the virtual table of revolutions, the stored totals are not used and the request is performed entirely according to the movement table.
Mechanism for imposing access restrictions.
Any operation on data stored in a database in 1C:Enterprise ultimately leads to a call to the database with some request to read or change the data. In the process of executing queries to the database, the internal mechanisms of 1C:Enterprise impose access restrictions. Wherein:
- A list of rights is generated(read, add, modify, delete), a list of database tables, and a list of fields used by this query.
- Of all the roles current user access restrictions are selected to data for all rights, tables and fields involved in the request. Moreover, if a role does not contain restrictions on access to the data of a table or field, this means that the values of the required fields from any record are available in this table. In other words, the absence of a data access restriction means the presence of a restriction WHERE IS Truth.
- Retrieves the current values of all session parameters and functional options participating in the selected restrictions.
To obtain the value of a session parameter or feature option, the current user does not need to have permission to obtain that value. However, if the value of some session parameter has not been set, an error will occur and the database query will not be executed.
Constraints derived from one role are combined using the AND operation.
Constraints derived from different roles are combined using the OR operation.
The constructed conditions are added to the SQL queries with which 1C: Enterprise accesses the DBMS. When accessing data from access restriction conditions, rights check is not performed (neither for metadata objects nor for database objects). Moreover, the mechanism for adding conditions depends on the selected method of operation of the restrictions “all” or “allowed”.
*Feature: If a user has access to several roles with configured restrictions at the record level for one object, then in this case the conditions of the restrictions are added using the logical operation “OR”. In other words, the user's powers are cumulative.
This leads to the following conclusion: do not allow the conditions for restricting access to one object in different roles to intersect, because in this case the text of the request will be greatly complicated and this will affect performance.
"Everything" method.
When imposing restrictions using the “all” method, conditions and fields are added to SQL queries so that 1C:Enterprise can obtain information about whether, during the execution of a database query, data that was prohibited for a given user was used or not. If prohibited data was used, the request will crash due to an access violation.
Imposing access restrictions using the “all” method is schematically presented in the figure:
“Allowed” method.
When applying restrictions using the “allowed” method, conditions are added to SQL queries so that records that are prohibited for the current user do not affect the result of the query. In other words, when imposing restrictions in the “allowed” mode, prohibited to this user records are considered missing and do not affect the result of the operation, which is shown schematically in the figure:
Data access restrictions are imposed on database objects at the time 1C:Enterprise accesses the database.
In the client-server version of 1C:Enterprise, restrictions are applied on the 1C:Enterprise server.
However, this option (ALLOWED) will not work if in a query we refer to a table for which access restrictions are not configured, but which contains references to table rows with configured restrictions. In this case, the query result will display “<Объект не найден>......" instead of the value of the reference field.
If you are developing a report or processing using standard or custom configuration queries, always check the "Allowed" flag for the report to work under any user with any set of rights.
In the case of object reading of data from the database, it is not possible to set the “Allowed” flag. Therefore it is necessary configure selections for object reading, taking into account possible access rights restrictions for the user. There are no means of obtaining only permitted data in object technology.
It is important that if a query does not specify the ALLOWED keyword, then all selections specified in that query must not conflict with any of the read restrictions on the database objects used in the query. Moreover, if the query uses virtual tables, then the corresponding selections must be applied to the virtual tables themselves.
Practice 1. Query builder in RLS settings.
Let’s compose the text of the “WHERE” section in the query to the directory. You can use the query builder.
The designer has a stripped down appearance.
“Tables” tab
The main table will be the table of the object for which the constraint is being configured.
You can also select other tables and set up various connections between them on the “Relations” tab.
Tab "Conditions"
Here you can configure the actual access restriction conditions
Let’s add conditions to the “Price” attribute of the nomenclature directory for the right to “read” to all fields of the table.
“Nomenclature WHERE Nomenclature.Price > 500”
Let's see how this simple rule works. The directory table contains the following elements:
After setting up an access restriction, the table will show only elements that satisfy the condition:
Groups also disappeared. Let's change the text of the restriction
“Nomenclature WHERE Nomenclature.Price > 500
OR Nomenclature.This is a Group"
Well, now that's what you need.
If you remove the display of the “code” field in the list settings, all elements of the directory will be displayed, i.e. the restriction didn't work. If you set the “Code” field to display, the restriction will work.
In this case, despite the fact that the directory element is visible in the list field, its form cannot be opened because a restriction on the attribute is configured. The same thing happens in an arbitrary request: when you try to get a “restricted” property, there will be an access error.
If you try to get the “restricted” credentials programmatically, an access error will also be thrown.
Moreover, it will not be possible to access any fields of an object through a link, because when receiving a link, the system reads the entire object, and if it contains “restricted” details, the object will not be read.
Therefore, when program work With database objects, you need to keep in mind possible restrictions at the record level and obtain all the necessary object data with a query and then place it in a structure or execute part of the code in a privileged module.
After setting up the access restriction, the display of the line in the list of rights changed - it became gray and an icon appeared.
Restrictions when setting up access (RLS).
- There is no Summary section;
- Virtual register tables cannot be accessed;
- You cannot use parameters explicitly;
- Can be used in nested queries any>/span> query language tools except:
- operator IN HIERARCHY;
- RESULTS proposals;
- nested query results must not contain table parts>/span>;
- virtual tables, in particular Balances and Turnovers
Practice 2. Nomenclature with current price.
Restrict access if you need to display items with the current price greater certain value, for example, 100.
Solution:
We are adding a new access restriction rule for the “Nomenclature” directory with the “read” right.
Select “other fields”.
In the constructor we add a nested query. In it, select the information register table “Item prices”.
There is no “order” tab - this is a feature of the query designer for building an access restriction request.
On the “Advanced” tab, set “first 999999999”, the “order” tab appears.
We set up ordering by the “Period” field in descending order.
Then we set up a connection between the main table and the subquery by reference.
Access Restriction Templates.
Practice 3. Restriction on “counterparties” by value in a constant.
Let's set up an access restriction for the Counterparties directory based on the value stored in the Constant.
In addition, you need to set up a restriction for all objects that use the “Counterparties” directory in the details.
Solution
For the “Counterparties” directory, we will set up a restriction for the “read” right by adding a nested query to the constant in the “Conditions” section. Don't forget This is a Group.
We see a problem, the Counterparties directory is filtered correctly, and all documents with the “Counterparty” attribute are displayed, some with “broken” links in the “Counterparty” attribute.
Now you need to configure access restrictions for all objects that use the link to “Accounts”. Let's find them using the “search for links to an object” service.
Let’s copy and slightly modify the text of the RLS condition from the “Counterparties” directory. This must be done as many times as there are objects found.
Or use an access restrictions pattern to avoid code duplication issues.
Access restriction templates are configured at the role level and can be used for any object within the edited role.
You can add any piece of access restriction text to the template. The template is called using the “#” symbol. For example, #TemplateCounterparty.
Through # in 1C instructions are written to the preprocessor. In the context of executing access restriction settings, the platform replaces the template call text with the template text.
Let’s add the text after the word WHERE to the “Contractor Template” template, except for the text about EtoGroup.
Parameters in access restriction templates.
Let's continue solving problem 2.
The problem now is that the main table in the directory is called “counterparty”, in the document “Receipt invoice”. The field being checked in the directory is called “link”, in the document it is called “Counterparty”.
Let’s change the name of the main table in the template text to “#CurrentTable”
"#CurrentTable" is a predefined parameter.
And through a dot we indicate the number of the input parameter - “.#Parameter(1)
“#Parameter” is also predefined value. Can contain an arbitrary number of input parameters. They are addressed by serial number.
In the text of the access restrictions for the directory, we indicate the following:
For the document the following:
“Sales of Goods WHERE #TemplateCounterparty (“Counterparty”)”
When calling an access restriction template, parameters must be passed to it only as a String, i.e. in quotes.
Main table - Nomenclature
The template text is:
#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)
The template text contains part of the text in the data access restriction language and may contain parameters that are highlighted using the “#” symbol.
The "#" symbol may be followed by:
- One of the keywords:
- A parameter followed by the number of the parameter in the template in parentheses;
- CurrentTable – indicates insertion into the text of the full name of the table for which the constraint is being built;
- CurrentTableName– denotes insertion into the text of the full name of the table (as a string value, in quotes) to which the instruction is applied, in the current version of the built-in language;
- NameCurrentAccessRight– contains the name of the right for which the current restriction is executed: READ, ADD, INSERT, CHANGE, UPDATE, DELETE;
- template parameter name – means insertion of the corresponding template parameter constraint into the text;
- symbol “#” – indicates the insertion of one character “#” into the text.
An access restriction expression may contain:
- Access restriction template, which is specified in the format #TemplateName("Template parameter value 1", "Template parameter value 2",...). Each template parameter is enclosed in double quotes. If it is necessary to specify a symbol parameter in the text double quotes two double quotes should be used.
- Function StrContains(WhereWeLook, WhatWeLook). The function is designed to search for an occurrence of the WhatWeLook string in the WhereWeLook string. Returns True if the occurrence is found and False otherwise.
- The + operator is for string concatenation.
To make it easier to edit the template text, on the Restriction templates tab in the role form, click the Set template text button. In the dialog that opens, enter the template text and click OK.
They cannot be installed using SetParameter() or something similar.
The parameters in this case are:
- Session Options
- Functional options
Reading of session parameters in an access restriction request occurs in privileged mode, that is, without controlling the rights to operate with them.
Practice 4. Access to “your” counterparties
It is necessary to configure restriction of the current user’s access to “their” counterparties.
There is a directory “Users”, a directory “Counterparties”, documents with the details “Counterparty”.
The current user should see data only for those counterparties for whom a connection has been established with him.
Communication also needs to be configured.
Possible options:
Establishing connections between user and counterparty
- Details in the counterparties directory
- Register of information
Possible solutions to the problem:
- Storing a user in a constant is a bad option; the constant is available to all users.
- Storing a fixed array of the current user's counterparties in the session parameters is not very good a good option, there can be many counterparties
- Storing in the session parameters of the current user, then requesting a list of “his” counterparties is an acceptable option.
- Other options.
Solution.
Let's create new parameter session “CurrentUser” and register its filling in the session module.
Let’s create a register of information “Compliance of managers and contractors”
Let's create a new role and in it a new access restriction for the document “Invoice”.
In the text of the request, we will connect the main table with the information register for Account = Account and Manager = &CurrentUser. Connection type Internal.
If possible, it is better to avoid nested queries in access restriction texts, since it will be executed every time data is read from this object from the database.
Checking - the restrictions work
*Feature: If you change the list of user counterparties in the register, access restrictions will take effect immediately without restarting the user session.
Practice 5. Date of prohibition of changes.
It is necessary to implement a restriction on editing data before the established date for prohibiting changes.
You need to limit it for users.
Let's create a register of information “Dates of Prohibition of Changes” with the dimension User, resource Date of Prohibition.
Let's build the logic of the solution this way:
- if a user is not specified, then the ban applies to all users
- if there is a restriction for all users and a restriction for a specific user, then the restriction applies for a specific user, and for others according to the general principle.
Obviously, such a constraint can be configured for database objects that have some position on the time axis. It can be
- Documentation
- Periodic information registers
Let's create a new role “Restrictions By Date of Prohibition of Changes”.
In it, for the document “Invoice” for the right “change” we will add a new access restriction.
We specify the setting for all fields.
The text of the restriction is:
ReceiptInvoice FROM Document.ReceiptInvoice AS ReceiptInvoice
Change Ban Dates. Ban Date AS Ban Date
FROM
INNER JOIN (SELECT
MAX(Change Prohibited Dates.User) AS User
FROM
Register of Information. Dates of Prohibition of Changes AS Dates of Prohibition of Changes
WHERE
(Change Prohibited Dates.User = &CurrentUser
OR Dates ProhibitedChanges.User = VALUE(Directory.users.EmptyLink))) AS VZ_User
BY Date of Prohibition of Changes.User = VZ_User.User) AS NestedQuery
Software Receipt Invoice.Date > Nested Query.Ban Date
Let's check - the restriction works.
Using Preprocessor Instructions
#If Condition1 #Then
Request fragment 1
#ElseIf Condition2 #Then
Request fragment 2
#Otherwise
Request fragment 3
#EndIf
In conditions it can be used logical operations(and. or, not, etc.) and accessing session parameters.
This approach in the context of constructing access restrictions is convenient in that, depending on the conditions, a shorter request text will be compiled. A simpler query loads the system less.
The downside is that the query constructor will not work with such text.
*Peculiarity :
In contrast to the instructions to the preprocessor of the built-in language in the access restriction texts, before the operator Then you need to put a hash - #Then
Practice 6. Switch “Use RLS”
Let's supplement our system of restrictions with a switch that turns on/off the use of restrictions at the record level.
To do this, we will add a Constant and a session parameter named “UseRLS”.
Let's write in the Session Module to set the value of the session parameter from the value of the constant.
Let's add the following code to all access restriction texts:
“#If &UseRLS #Then….. #EndIf”
We check - everything works.
However, now after turning on the “use radar” flag, the changes will not immediately take effect. Why?
Because the session parameter is set when the session is started.
You can make it so that when a new constant value is written, the value of the session parameter is reset, but this will only work for current session user. Other users should be prompted to restart the system.
End of the first part.
In this article I will tell you how the “record-level access restriction” configuration mechanism works in 1C:UPP 1.3. The information for the article was collected as of May 2015. Since then, the UPP has not been radically updated, because 1C chose 1C:ERP as its flagship. Still, the UPP works properly in many enterprises, so I am posting the results of my research on RLS in the UPP in this article. It will definitely be useful to someone.
Everything is dry, compressed and without water. How I love))).
Access rights settings.
Scheme of interaction of objects.
In UPP 1.3, access control is carried out by the “Access Control” subsystem from BSP version 1.2.4.1.
Metadata used in the access control system in the UPP:
- Reference “User Permission Profiles”
- Information register “Values of additional user rights”
- Plan of types of characteristics “User rights”
- Directory "Users"
- System directory “IS Users”
- Directory "User Groups"
- Register of information "User settings"
- Plan of characteristics types “User settings”
- Enumeration “Types of access objects”
- Register of information “Purpose of types of access restrictions”
- Enumeration “Data Areas of Access Objects”
- Information register “User access rights settings”
- Session option "Use limit by<ВидДоступа>».
Enable record-level access restrictions.
Record Level Access Restriction (RLS) is enabled in the interface
“User Administration” -> “Record Level Access” -> “Settings”.
Record-level access is defined through access object types. List of types of access objects (the corresponding directories are indicated in brackets):
- "Counterparties" ("Counterparties")
- "Organizations" ("Organizations")
- « Individuals» (“Individuals”)
- "Projects" ("Projects")
- “Warehouses (“Warehouses (storage places)”)
- "Candidates" ("Candidates")
- Notes (Note Entry Types)
- "Divisions" ("Divisions")
- "Divisions of organizations" ("Divisions of the organization")
- “Nomenclature (change)” (“Nomenclature”)
- "Specifications" ("Specifications")
- “Item prices” (“Item price types”)
- "External processing" ("External processing")
*The list of possible types of access is fixed and is contained in the “Types of access objects” enumeration.
Directory "User Permission Profiles".
Setting up access to objects information base begins with setting up a user permissions profile.
Profile unites
- a set of roles – access rights to objects
- additional user rights – rights to functionality programs.
The result of setting up a profile is an entry in the information register “Values of additional user rights”.
This register is not used in radar configuration.
Additional rights can be recorded for a profile or user. Moreover, if additional rights are configured for a profile and the profile is associated with a user, then additional rights cannot be configured individually for the user.
*The list of rights is listed in terms of types of characteristics “User Rights”
The profile itself in the “roles list” tabular section contains all the roles that are enabled for it. When the composition of profile roles changes, the “Roles” tabular part of all users of the information base (not the “Users” directory) to whom this profile is assigned is refilled.
The connection between the directory “Users” and “Information Base Users” is implemented through the attribute “IB User Identifier” of the directory “Users”, which stores the GUID of the IS user.
The composition of user roles is also not available for editing if the user is assigned a specific profile.
It is possible for the user to specify “User Settings”. These are different service settings typical automatic behavior of the system in certain situations.
The result of the settings is recorded in the “User Settings” information register.
The list of settings and their possible values is contained in the “User Settings” characteristic type plan.
*Not used in record-level access restriction settings.
Directory "User Groups".
Used to organize users into groups and, among other things, to configure access restrictions at the record level.
One user can be included in several groups.
In the user group form, you can configure a list of access types.
Record-level object permissions are configured only for user groups, not individual users.
If your configuration uses record-level access restrictions, then each user must be included in one of the groups.
IMPORTANT! Users who are not included in any group will not be able to work with those objects whose access is determined at the record level. This applies to all objects - regardless of whether the corresponding access object types are used or not.
If a user belongs to several groups that have different settings access rights at the record level, then the availability of the object for the user will be determined by combining the settings from several user groups using “OR”.
IMPORTANT! Including a user in a large number of groups can lead to slow performance. Therefore, you should not include a user in a large number of groups.
After recording changes to a user group, the Information Register “Assignment of access restriction types” will be filled in. This register stores records of compliance with a user group for a certain type of access.
*Case is used in access restriction templates
“Access Settings” form.
The form for setting access restrictions at the record level is called by the “Access Settings” command of the “User Groups” directory list form.
On the right side of the form, tabs present tables with settings for each type of access, marked with checkboxes in the user group form.
The access rights setting form has a separate form page for each type of access with its own set of settings. The required page is enabled when the access type associated with it is checked in the user group.
Comparison of access types and possible settings:
|
Type of access |
Access type settings |
|||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Reading |
Record |
Type of access rights inheritance |
Visibility in the list |
View additional information |
Editing additional information |
View data |
Editing data |
Company prices |
Counter agent prices |
|||
|
Reading |
Record |
Reading |
Record |
|||||||||
| Counterparties | ||||||||||||
| Organizations | ||||||||||||
| Individuals | ||||||||||||
| Projects | ||||||||||||
| Warehouses | ||||||||||||
| Candidates | ||||||||||||
| Notes | ||||||||||||
| Divisions | ||||||||||||
| Organizational divisions | ||||||||||||
| Nomenclature | ||||||||||||
| Specifications | ||||||||||||
| Item prices | ||||||||||||
| External treatments | ||||||||||||
Access rights.
“Reading” - the user will see the directory item in the list and will be able to open it for viewing, and will also be able to select it from the list when filling in the details of other objects.
“Record” - the user will be able to change:
- elements of some directories - types of access objects (not all - there are exceptions, see below),
- data (documents, registers, subordinate directories) associated with these directory elements
Exception: access to elements of some directories - types of access objects - does not depend on the “Write” right. These are directories: Organizations, Divisions, Divisions of Organizations, Warehouses, Projects. They relate to master data objects, so only a user with the “Master data setup...” role can change them.
For the access object type " Nomenclature (change)"The access right to "record" is defined only at the group level of the "Nomenclature" directory; it is not possible to set the "record" right for individual element reference book.
There is no restriction on access to “reading” the “Nomenclature” reference book and related information, because in general it is unclear what kind of access should be given to a document if the list of nomenclature that is in the document contains both “allowed” and “prohibited” » positions.
The restriction of access for the directories “Divisions” and “Divisions of Organizations” does not apply to information on personnel data, personal data of employees and payroll data.
Data areas.
Data areas are defined for the following types of access objects:
- Counterparties
- Individuals
- Item prices
For the access object type “Counterparties”
- Counterparties (list)— determines the visibility of counterparties in the list of the “Counterparties” directory. Depends on the value of the checkbox in the “Visibility in the list” column.
- Contractors (additional information)— determines the ability to “read”/“write” the directory element “Counterparties” and the additional information associated with it. information (contracts, contact persons, etc.). Depends on the value of the checkbox in the corresponding columns “View additional. information"/"Editing additional information" information."
- Counterparties (data)— determines the ability to “read”/“write” data (directories, documents, registers) associated with the “Counterparties” directory. Depends on the value of the checkbox in the “View data”/“Edit data” column.
For the access object type “Individuals” The following data areas are provided:
- Individuals (list)— determines the visibility of an individual in the list of the “Individuals” directory. Depends on the value of the checkbox in the “Visibility in the list” column.
- Individuals (data)— determines the ability to “read”/“write” data (directories, documents, registers) associated with the “Individuals” directory. Depends on the value of the checkbox in the “View data”/“Edit data” column.
For the access object type “Item prices” The following data areas are provided:
- Company prices—defines the ability to “read”/“write” prices for the company’s items.
- Contractor prices— determines the ability to “read”/“write” the prices of counterparties’ items.
*Data areas are a closed list of elements contained in the “Data areas of access objects” enumeration
Access groups.
For the following types of access objects, rights settings are performed only through access groups (the names of the directory are indicated in brackets):
- “Counterparties” (“Counterparty access groups”)
- “Individuals” (“Access groups of individuals”)
- “Candidates” (“Groups of Candidates”)
- “Item Specifications” (“Purposes of using specifications”)
The access group is indicated for each directory element (in a special attribute).
Access settings from the “access group...” are carried out in an additional form for setting access rights, which is called by one of two commands:
- "Access current items"
- "Access to the directory as a whole"
in the form of a list of “Access groups...” directories
Example: Document " Receipt order for goods" is limited by the types of access objects "Counterparties", "Organizations", "Warehouses".
If you provide access to an empty value for the “Counterparties” access type, the user will see documents in which the “Counterparties” attribute is not filled in.
Access to a directory element or group.
Depending on whether access to a directory element or a group is being configured, the setting affects either the element itself or subordinate groups.
According to this, in the “Setting up access rights” form in the “Type of access rights inheritance” column hierarchical directories» the following values are set:
- Only for current permission– for a directory element, rights apply to the specified element
- Distribute to subordinates– for a directory group, rights apply to all subordinate elements
After recording the access restriction settings for user groups, the “User Access Rights Settings” Information Register will be filled in the system.
*Case is used in access restriction templates.
Using templates.
Templates in UPP 1.3 are written for each type of access separately and for possible combinations of access types, as a rule, for each user group.
For example , in the demo version of UPP, the “Purchases” user group is configured. For this group, the use of access types “Organizations”, “Counterparties”, “Warehouses” is enabled. Accordingly, a number of access restriction templates have been created in the system:
- "Organization"
- "Organization_Record"
- "Counterparties"
- "Counterparties_Record"
- "Warehouses"
- "Warehouses_Record"
- "CounterpartyOrganization"
- "CounterpartyOrganization_Record"
- "OrganizationWarehouse"
- "OrganizationWarehouse_Record"
- “CounterpartyOrganizationWarehouse_Record”
- "CounterpartyWarehouse"
- "CounterpartyWarehouse_Record"
That is, all possible combinations of access types that can be used in access restriction texts.
In general, the template construction scheme is the same for all types of access and looks like this:
- Checking the inclusion of the type of access being checked.
- The “User Groups” directory is attached to the main table and it is checked that the user is included in at least one group.
- The register table “Settings of user access rights” according to connection conditions is attached to the information register “Assignment of types of access values” — The access object is the access value passed to the template parameter. — Type of access object – depends on the context of template development — Data area.- User.
The result of the connection determines whether access is allowed or not.
End of the second part.
The RLS mechanism in 1C (record-level access restrictions) allows the developer to set his own selections and conditions directly on database tables. Such restrictions may apply to reading, adding, modifying, and deleting.
The main disadvantage of the method is the reduction in the performance of the system as a whole. The point is that additional selections are added to the main queries that dynamically retrieve data. Every time the user accesses any data in the infobase that is subject to a restriction, the program will perform a check by executing a query.
Despite this significant drawback, the RLS mechanism is quite convenient and flexible. With its help, you can configure the system so that not a single user sees anything “unnecessary”. Limiting the access of your employees, especially if there are many of them, is very productive. The point is not so much distrust, but protection from random errors and the human factor. The less data is available, the easier it is to work with it and not get confused.
In one of our articles, we already partially touched on the topic of restricting access at the record level. In this case, more in-depth configuration on the developer’s part will be considered.
Configuring entry-level access restrictions
Configuration and development of the radar is carried out in the 1C configurator. To do this, first create a role in the metadata branch.
On the “Constraint Templates” tab, you can create one or several such templates. Outwardly, they are practically no different from the usual requests.
Next, go to the “Rights” tab of the role for which you want to set a restriction. For convenience, you can use the query designer, which has only two tabs “Tables and fields” and “Conditions”.
As you can see in the image below, we have added only one constraint with text:
WHEREProductGroup = &ProductGroup
As a result, when the user accesses the “Nomenclature” directory, the program will add a line with this condition to all requests.
The 1C program has a built-in access rights system, which is located in Configurator - General - Roles.
How is this system characterized and what is its main purpose? It allows you to describe sets of rights that correspond to user positions or types of activities. This system access rights are static in nature, which means that as the administrator set the access rights to 1C, so it is. In addition to the static one, there is a second access rights system - dynamic (RLS). In this system, access rights are calculated dynamically, depending on given parameters, in process of work.
Roles in 1C
To the most common security settings in different programs is the so-called set of read/write permissions for various user groups and in the future: inclusion or exclusion of a specific user from groups. Such a system, for example, is used in the operating room Windows system AD ( Active Directory). Security system used in software 1C, got the name - roles. What it is? Roles in 1C is an object that is located in the configuration in the branch: General - Roles. These 1C roles are groups for which rights are assigned. In the future, each user can be included or excluded from this group.
By double-clicking on the role name, you will open the rights editor for the role. On the left there is a list of objects, mark any of them and on the right you will see options for possible access rights:
— reading: obtaining records or their partial fragments from a database table;
— adding: new records while saving existing ones;
- change: making changes to existing records;
— deleting: some records, leaving the rest unchanged.
Note that all access rights can be divided into two main groups - this is a “just” right and this is exactly the right with the addition of the “interactive” characteristic. What does this mean? And the point is this.
In the case when the user opens some form, for example processing, and at the same time clicks on it with the mouse, the program in the built-in 1C language begins to perform specific actions, deleting documents, for example. “Simply” 1C rights are responsible for allowing such actions performed by the program.
In the case when a user opens a journal and begins to independently enter something from the keyboard (new documents, for example), then 1C “interactive” rights are responsible for allowing such actions. Each user can have access to several roles at once, then the permission is added up.
RLS in 1C
You can enable access to the directory (or document) or disable it. You can’t “turn it on a little.” For this purpose, there is a certain extension of the 1C role system, which is called RLS. This is a dynamic access rights system that introduces partial restrictions on access. For example, only documents of a certain organization and warehouse become available to the user, and he does not see the rest.
It should be borne in mind that the RLS system must be used very carefully, since its intricate scheme is quite difficult to understand; different users may have questions when, for example, they compare the same report, which is generated from different users. Let's consider this example. You select a specific directory (organizations, for example) and a specific right (reading, for example), that is, you allow reading for the 1C role. In this case, in the remote panel Data Access Restrictions, you set the text of the request, according to which it is set to False or True, depending on the settings. Typically, settings are saved in a special information register.
This request will be executed dynamically (when attempting to organize reading) for all directory entries. It works like this: those records for which the security request has assigned - True, the user will see, but others will not. 1C rights with established restrictions are highlighted in gray.
The operation of copying identical RLS settings is performed using templates. To begin with, you create a template, calling it, for example, MyTemplate, in which you reflect the security request. Then, in the access rights settings, specify the name of this template in this way: “#MyTemplate”.
When a user works in 1C Enterprise mode, when connecting to RLS, an error message like: “Insufficient rights” (to read the XXX directory, for example) may appear. This indicates that the RLS system is blocked from reading some records. To prevent this message from appearing again, you need to enter the word ALLOWED in the request text.
There is often a need to partially restrict access to data. For example, when a user should see documents only from his organization. In such cases, 1C uses a mechanism for restricting access at the record level (the so-called RLS - Record Level Securiy).
For example, let's assume that we are faced with the following task. The enterprise maintains multi-company accounting and each counterparty and database user belongs to a specific organization. It is necessary to provide access to the “Counterparties” directory in such a way that each user can view, edit and add contractors only for his organization.
To solve the problem we will use the 1C:Enterprise 8.2 platform. Let's create new configuration in the properties of which the “Managed application” option will be selected as the main launch mode.
Next, we will create a directory “Organizations” and two more directories – “Counterparties” and “Users” with the requisite “Organization”. In addition to directories, we will need two session parameters – “Organization” and “User” (of appropriate types). The values of these parameters are set when a configuration session starts and are stored until it ends. It is the values of these parameters that we will use when adding access restriction conditions at the record level.
Setting session parameters is performed in a special module – “Session Module”
In this module we will describe the predefined procedure “SettingSessionParameters” in which we will call the function of a previously prepared common module“Full Rights”. This is necessary due to the peculiarities of the database operating in managed application mode, when part of the program code can only be executed on the server side (I will not dwell on explaining these principles in detail in this article).
Code 1C v 8.x Procedure Setting Session Parameters (Required Parameters)
FullPermissions.SetSessionParameters();
End of Procedure
In the properties of the “Full Rights” module, you must check the “Server”, “Call server” and “Privileged” checkboxes (the latter means that the procedures and functions of this module will be executed without access rights control). The module text will look like this:
Code 1C v 8.x Function DetermineCurrentUser()
TechUser = Directories.Users.FindByName(UserName(), True);
Return TechUser;
EndFunction
Procedure SetSessionParameters() Export
CurrentUser = DefineCurrentUser();
CurrentOrganization = Directories.Organizations.EmptyLink();
If ValueFilled(CurrentUser) Then
CurrentOrganization = CurrentUser.Organization;
endIf;
SessionParameters.User = CurrentUser;
SessionParameters.Organization = CurrentOrganization;
End of Procedure
FunctionSessionParameterSet(ParameterName) Export
Return ValueFilled(SessionParameters[ParameterName]);
EndFunction
Function RoleAvailable to User(RoleName) Export
return RoleAvailable(RoleName);
EndFunction
In the managed application module, we will check for the presence of a configuration user in the “Users” directory (for simplicity, we will search for it by name) and shut down the system if it is not found. This is necessary to ensure that the session parameters are filled in.
Code 1C v 8.x Procedure Before Starting the System (Failure)
// we will check everyone except the administrator for presence in the "Users" directory
If Not FullRights.RoleAvailableToUser("FullRights") Then
If NOT FullRights.SessionParameterSet("User") Then
Warning("User """ + UserName() + """ not found in the directory!");
Refuse = True;
Return;
endIf;
endIf;
End of Procedure
Now we can move directly to the description of access restrictions. To do this, create the “User” role and go to the “Restriction Templates” tab, where we add a new template “AccountsReadingChange” with the following template text: WHERE Organization =Organization #Parameter(1)
Constraint pattern text is an extension of the query language. Unlike a regular request, the text of the restriction must necessarily contain the “WHERE” condition. The values of the session parameters of the same name are used as the values of the request parameters (in our case, “&Organization”). A construction like #Parameter(1) means that in this place the system will substitute the text passed as the first parameter where the template is used. Using the template provided, each table entry will be checked (in our case, this will be the “Counterparties” directory). For records whose “Organization” attribute value matches that specified in the corresponding session parameter, the condition described in the template will be met. This way, these records will be available for reading, editing or adding (depending on which of these rights the template applies to). I will demonstrate the above using our example.
Let’s go to the “Rights” tab of the “User” role and open the list of rights in the “Counterparties” directory. We will use the “AccountsReadingChange” restriction template for the “Reading”, “Changing” and “Adding” rights.
For the “Read” right, we will use a template with the “OR ThisGroup” parameter. In this case, users of this role will be allowed to read not only elements of the “Accounts” directory of their organization, but also all groups of this directory.
#CounterpartiesReadChange("OR ThisGroup")
Since when adding new directory elements, the system implicitly reads predefined details (this is necessary, for example, for numbering), it is necessary to ensure unhindered reading of these fields. To do this, add an additional line with empty restriction text to the data access restriction table and list the fields for which it is valid this rule– Reference, Data Version, Parent, Code.
Thus, the task of restricting access at the record level has been solved. Users with existing restrictions will only have access to view and edit data for their organization.
Loading...
