Usando RLS. Cuaderno del programador 1C que restringe el acceso a ejemplos de datos

En este artículo te contaré cómo funciona el mecanismo de configuración de “restricción de acceso a nivel de registro” en 1C:UPP 1.3. La información para el artículo fue recopilada a partir de mayo de 2015. Desde entonces, la UPP no se ha actualizado radicalmente, porque 1C eligió 1C:ERP como su buque insignia. Aún así, la UPP funciona correctamente en muchas empresas, por lo que publico los resultados de mi investigación sobre RLS en la UPP en este artículo. Definitivamente será útil para alguien.

Todo está seco, comprimido y sin agua. Cómo me encanta))).

Configuración de derechos de acceso.

Esquema de interacción de objetos.

En UPP 1.3, el control de acceso lo realiza el subsistema “Control de acceso” de BSP versión 1.2.4.1.

Metadatos utilizados en el sistema de control de acceso en la UPP:

1. Referencia "Perfiles de permisos de usuario"
2. Registro de información “Valores de derechos de usuario adicionales”
3. Plan de tipos de características “Derechos de Usuario”
4. Directorio "Usuarios"
5. Libro de referencia del sistema "Usuarios de IS"
6. Directorio "Grupos de usuarios"
7. Registro de información "Configuración de usuario"
8. Plan de tipos de características “Configuración de usuario”
9. Enumeración “Tipos de objetos de acceso”
10. Registro de información “Finalidad de los tipos de restricciones de acceso”
11. Enumeración “Áreas de datos de objetos de acceso”
12. Registro de información “Configuración de derechos de acceso de usuario”
13. Opción de sesión "Límite de uso por<ВидДоступа>».

Habilite las restricciones de acceso a nivel de registro.

La limitación del nivel de registro (RLS) está habilitada en la interfaz
“Administración de usuarios” -> “Acceso a nivel de registro” -> “Configuración”.

El acceso a nivel de registro se define mediante tipos de objetos de acceso. Lista de tipos de objetos de acceso (los directorios correspondientes se indican entre paréntesis):

• "Contrapartes" ("Contrapartes")
• "Organizaciones" ("Organizaciones")
• “Individuos” (“Individuos”)
• "Proyectos" ("Proyectos")
• “Almacenes (“Almacenes (lugares de almacenamiento)”)
• "Candidatos" ("Candidatos")
• Notas (tipos de entrada de notas)
• "Divisiones" ("Divisiones")
• "Divisiones de organizaciones" ("Divisiones de la organización")
• “Nomenclatura (cambio)” (“Nomenclatura”)
• "Especificaciones" ("Especificaciones")
• “Precios de artículos” (“Tipos de precios de artículos”)
• "Procesamiento externo" ("Procesamiento externo")

*La lista de posibles tipos de acceso es fija y está contenida en la enumeración “Tipos de objetos de acceso”.

Directorio "Perfiles de permisos de usuario".

La configuración del acceso a los objetos de la base de datos comienza con la configuración de un perfil de permisos de usuario.

Perfil une

• un conjunto de roles: derechos de acceso a los objetos
• derechos de usuario adicionales: derechos sobre la funcionalidad del programa.

El resultado de configurar un perfil es una entrada en el registro de información "Valores de derechos de usuario adicionales".
Este registro no se utiliza en la configuración del radar.

Se pueden registrar derechos adicionales para un perfil o usuario. Además, si se configuran derechos adicionales para un perfil y el perfil está asociado con un usuario, entonces no se pueden configurar derechos adicionales individualmente para el usuario.
*La lista de derechos se enumera en términos de tipos de características “Derechos del Usuario”

El perfil en sí en la sección tabular "lista de roles" contiene todos los roles que están habilitados para él. Cuando cambia la composición de los roles del perfil, se vuelve a llenar la parte tabular "Roles" de todos los usuarios de la base de información (no el directorio "Usuarios") a quienes se asigna este perfil.

La conexión entre el directorio “Usuarios” y “Usuarios de la Base de Información” se implementa a través del atributo “Identificador de Usuario IB” del directorio “Usuarios”, que almacena el GUID del usuario IS.

La composición de las funciones de los usuarios tampoco está disponible para editar si al usuario se le asigna un perfil específico.

Es posible que el usuario especifique "Configuración de usuario". Se trata de diversas configuraciones de servicio para el comportamiento automático típico del sistema en determinadas situaciones.

El resultado de la configuración se registra en el registro de información "Configuración de usuario".

La lista de configuraciones y sus posibles valores está contenida en el plan de tipo de característica "Configuración de usuario".
*No se utiliza en configuraciones de restricción de acceso a nivel de registro.

Directorio "Grupos de Usuarios".

Se utiliza para organizar a los usuarios en grupos y, entre otras cosas, para configurar restricciones de acceso a nivel de registro.

Un usuario puede estar incluido en varios grupos.

En el formulario del grupo de usuarios, puede configurar una lista de tipos de acceso.

Los permisos de objetos a nivel de registro se configuran solo para grupos de usuarios, no para usuarios individuales.

Si su configuración utiliza restricciones de acceso a nivel de registro, cada usuario debe estar incluido en uno de los grupos.

¡IMPORTANTE! Los usuarios que no estén incluidos en ningún grupo no podrán trabajar con aquellos objetos cuyo acceso esté determinado a nivel de registro. Esto se aplica a todos los objetos, independientemente de si se utilizan o no los tipos de objetos de acceso correspondientes.

Si un usuario es miembro de varios grupos que tienen diferentes configuraciones de derechos de acceso a nivel de registro, entonces la disponibilidad de un objeto para el usuario se determinará combinando las configuraciones de varios grupos de usuarios usando "O".

¡IMPORTANTE! Incluir a un usuario en una gran cantidad de grupos puede provocar un rendimiento lento. Por lo tanto, no debes incluir un usuario en una gran cantidad de grupos.

Luego de registrar los cambios en el grupo de usuarios, se completará el Registro de Información “Asignación de tipos de restricción de acceso”. Este registro almacena registros de cumplimiento de un grupo de usuarios para un determinado tipo de acceso.

*El caso se utiliza en plantillas de restricción de acceso.

Formulario “Configuración de acceso”.

El formulario para configurar restricciones de acceso a nivel de registro se llama mediante el comando "Configuración de acceso" del formulario de lista del directorio "Grupos de usuarios".

En el lado derecho del formulario, las pestañas presentan tablas con configuraciones para cada tipo de acceso, marcadas con casillas de verificación en el formulario del grupo de usuarios.

El formulario de configuración de derechos de acceso tiene una página de formulario separada para cada tipo de acceso con su propio conjunto de configuraciones. La página requerida se habilita cuando el tipo de acceso asociado a ella se marca en el grupo de usuarios.

Comparación de tipos de acceso y posibles configuraciones:

Tipo de acceso	Configuración del tipo de acceso
	Lectura	Registro	Tipo de herencia de derechos de acceso	Visibilidad en la lista	Ver información adicional	Editar información adicional	Ver datos	Editar datos	Precios de empresa		Precios de contraagente
									Lectura	Registro	Lectura	Registro
Contrapartes
Organizaciones
Individuos
Proyectos
Almacenes
Candidatos
Notas
Divisiones
Divisiones organizativas
Nomenclatura
Presupuesto
Precios de los artículos
Tratamientos externos

Derechos de acceso.

“Lectura”: el usuario verá el elemento del directorio en la lista y podrá abrirlo para verlo, y también podrá seleccionarlo de la lista al completar los detalles de otros objetos.

“Grabar" - el usuario podrá cambiar:

• elementos de algunos directorios - tipos de objetos de acceso (no todos - hay excepciones, ver más abajo),
• datos (documentos, registros, directorios subordinados) asociados con estos elementos del directorio

Excepción: el acceso a elementos de algunos directorios (tipos de objetos de acceso) no depende del derecho de “Escritura”. Estos son directorios: Organizaciones, Divisiones, Divisiones de Organizaciones, Almacenes, Proyectos. Se relacionan con objetos de datos maestros, por lo que solo un usuario con el rol "Configuración de datos maestros..." puede cambiarlos.

Para el tipo de objeto de acceso " Nomenclatura (cambio)"El derecho de acceso a "registro" se define sólo en el nivel de grupo del directorio "Nomenclatura"; no es posible establecer el derecho de "registro" para elemento individual libro de referencia.

No hay restricción de acceso para “leer” el libro de referencia de “Nomenclatura” y la información relacionada, porque en general no está claro qué tipo de acceso se debe dar a un documento si la lista de nomenclatura que está en el documento contiene tanto “permitidos” como Posiciones ” y “prohibidas” ».

La restricción de acceso a los directorios “Divisiones” y “Divisiones de Organizaciones” no se aplica a la información sobre datos del personal, datos personales de los empleados y datos de nómina.

Áreas de datos.

Las áreas de datos se definen para los siguientes tipos de objetos de acceso:

• Contrapartes
• Individuos
• Precios de los artículos

Para el objeto de acceso escriba “Contrapartes”

• Contrapartes (lista)— determina la visibilidad de las contrapartes en la lista del directorio “Contrapartes”. Depende del valor de la casilla de verificación en la columna "Visibilidad en la lista".
• Contratistas (información adicional)— determina la capacidad de “leer”/“escribir” el elemento del directorio “Contrapartes” y la información adicional asociada a él. información (contratos, personas de contacto, etc.). Depende del valor de la casilla de verificación en las columnas correspondientes “Ver adicional. información"/"Edición de información adicional" información."
• Contrapartes (datos)— determina la capacidad de “leer”/“escribir” datos (directorios, documentos, registros) asociados al directorio “Contrapartes”. Depende del valor de la casilla de verificación en la columna "Ver datos"/"Editar datos".

Para el objeto de acceso escriba “Particulares” Se proporcionan las siguientes áreas de datos:

• Individuos (lista)— determina la visibilidad de una persona en la lista del directorio “Personas”. Depende del valor de la casilla de verificación en la columna "Visibilidad en la lista".
• Individuos (datos)— determina la capacidad de “leer”/“escribir” datos (directorios, documentos, registros) asociados al directorio “Personas”. Depende del valor de la casilla de verificación en la columna "Ver datos"/"Editar datos".

Para el objeto de acceso escriba “Precios de artículos” Se proporcionan las siguientes áreas de datos:

• Precios de la empresa: define la capacidad de “leer”/“escribir” precios para los artículos de la empresa.
• Precios de contratista— determina la capacidad de “leer”/“escribir” los precios de los artículos de las contrapartes.

*Las áreas de datos son una lista cerrada de elementos contenidos en la enumeración “Áreas de datos de objetos de acceso”

Grupos de acceso.

Para los siguientes tipos de objetos de acceso, la configuración de derechos se realiza solo a través de grupos de acceso (los nombres del directorio se indican entre paréntesis):

• “Contrapartes” (“Grupos de acceso de contrapartes”)
• “Individuos” (“Acceso a grupos de individuos”)
• “Candidatos” (“Grupos de Candidatos”)
• “Especificaciones del artículo” (“Propósitos del uso de las especificaciones”)

El grupo de acceso se indica para cada elemento del directorio (en un atributo especial).

La configuración de acceso desde el “grupo de acceso...” se realiza en un formulario adicional para configurar los derechos de acceso, que se llama mediante uno de dos comandos:

• "Acceder a los artículos actuales"
• "Acceso al directorio en su totalidad"

en forma de lista de directorios de “Grupos de acceso...”

Ejemplo: El documento “Orden de recepción de mercancías” está limitado por los tipos de objetos de acceso “Contrapartes”, “Organizaciones”, “Almacenes”.

Si proporciona acceso a un valor vacío para el tipo de acceso “Contrapartes”, el usuario verá documentos en los que el atributo “Contrapartes” no está completado.

Acceso a un elemento o grupo del directorio.

Dependiendo de si se está configurando el acceso a un elemento del directorio o a un grupo, la configuración afecta al propio elemento o a los grupos subordinados.

De acuerdo con esto, en el formulario “Configuración de derechos de acceso”, en la columna “Tipo de herencia de derechos de acceso a directorios jerárquicos”, se establecen los siguientes valores:

• Sólo para permiso actual– para un elemento de directorio, los derechos se aplican al elemento especificado
• Distribuir a subordinados– para un grupo de directorio, los derechos se aplican a todos los elementos subordinados

Después de registrar la configuración de restricción de acceso para grupos de usuarios, se completará el registro de información "Configuración de derechos de acceso del usuario" en el sistema.

*El caso se utiliza en plantillas de restricción de acceso.

Usando plantillas.

Las plantillas en UPP 1.3 están escritas para cada tipo de acceso por separado y para posibles combinaciones de tipos de acceso, como regla general, para cada grupo de usuarios.

Por ejemplo , en la versión demo de UPP se configura el grupo de usuarios “Compras”. Para este grupo se habilita el uso de los tipos de acceso “Organizaciones”, “Contrapartes”, “Almacenes”. En consecuencia, se han creado una serie de plantillas de restricción de acceso en el sistema:

• "Organización"
• "Registro_Organización"
• "Contrapartes"
• "Registro_contrapartes"
• "Almacenes"
• "Almacenes_Registro"
• "Organización de contraparte"
• "CounterpartyOrganization_Record"
• "OrganizaciónAlmacén"
• "OrganizaciónAlmacén_Registro"
• “ContraparteOrganizaciónAlmacén_Registro”
• "Almacén de contraparte"
• "ContraparteWarehouse_Record"

Es decir, todas las combinaciones posibles de tipos de acceso que se pueden utilizar en los textos de restricción de acceso.

En general, el esquema de construcción de la plantilla es el mismo para todos los tipos de acceso y tiene el siguiente aspecto:

1. Comprobando la inclusión del tipo de acceso que se está comprobando.
2. Se adjunta a la tabla principal el directorio “Grupos de Usuarios” y se comprueba que el usuario esté incluido en al menos un grupo.
3. La tabla de registro “Configuración de los derechos de acceso de los usuarios” según las condiciones de conexión se adjunta al registro de información “Asignación de tipos de valores de acceso” — El objeto de acceso es el valor de acceso pasado al parámetro de plantilla. — Tipo de objeto de acceso: depende del contexto de desarrollo de la plantilla — Área de datos.- Usuario.

El resultado de la conexión determina si se permite el acceso o no.

Fin de la segunda parte.

Imprimir (Ctrl+P)

Restringir el acceso a los datos

El mecanismo de restricción de acceso a datos (también conocido como RLS, Row Level Security) le permite gestionar los derechos de acceso no sólo a nivel de objetos de metadatos, sino también a nivel de objetos de base de datos 1C:Enterprise. Para restringir el acceso a los datos, se pueden utilizar los siguientes objetos 1C:Enterprise:
● roles,
● parámetros de sesión,
● opciones funcionales,
● módulos comunes privilegiados,
● palabra clave PERMITIDA en el lenguaje de consulta.
Compartir los objetos enumerados permite la máxima flexibilidad cuando es necesario diferenciar los derechos de acceso a los datos entre usuarios que realizan diferentes funciones.
Se pueden imponer restricciones de acceso a los datos en las siguientes operaciones de datos (derechos de acceso): leer (derecho de lectura), agregar (derecho de agregar), modificar (derecho de cambio) y eliminar (derecho de eliminar). El usuario actual podrá realizar la operación requerida en los siguientes casos:
● Para operaciones de lectura y eliminación, el objeto que reside en la base de datos debe cumplir con una restricción de acceso a datos.
● Para una operación de adición, la restricción de acceso a datos debe coincidir con el objeto que planea escribir en la base de datos.
● Para una operación de cambio, la restricción de acceso a datos debe coincidir con el objeto tanto antes del cambio (para que el objeto se lea) como después del cambio (para que el objeto se escriba).
Al aplicar restricciones de acceso a datos, recuerde que puede especificar solo una condición para las operaciones de modificación, adición y eliminación, pero puede especificar más de una restricción de acceso a datos para una operación de lectura. Esto significa que se pueden establecer diferentes condiciones para leer diferentes campos de un objeto y, al configurar una condición, puede especificar tanto el nombre de un campo específico como el campo especial Otros campos. En el primer caso, la condición se impondrá solo si la selección (que lee los datos) contiene un campo para el cual se establece la restricción, y en el segundo caso, la restricción se impondrá para todos los campos del objeto, excepto para campos para los cuales se establecen restricciones explícitamente.
Al establecer una restricción en un campo específico, este campo se leerá si se cumple la restricción, y al establecer una restricción en Otros campos, los datos del objeto se leerán solo si la restricción se cumple para todos los campos del objeto incluidos en el Solicitud de lectura de datos.
Para los siguientes tipos de objetos de base de datos, se pueden imponer varias restricciones a diferentes tipos de cambios (agregar, modificar, eliminar):
● Planes de intercambio,
● Directorios,
● Documentos,
● Planes para tipos de características,
● Planes de cuentas,
● Planes para tipos de cálculo,
● Procesos de negocio,
● Tareas.
Para los siguientes tipos de objetos de bases de datos, es posible imponer restricciones a la lectura no solo del objeto completo, sino también de sus campos individuales:
● Planes de intercambio,
● Directorios,
● Documentos,
● Registros de documentos,
● Planes para tipos de características,
● Planes de cuentas,
● Planes para tipos de cálculo,
● Registros de información,
● Procesos de negocio,
● Tareas.
¡ATENCIÓN! Al acceder a los campos de los objetos de la base de datos utilizando las propiedades de los objetos de la aplicación desde el lenguaje integrado 1C:Enterprise, se lee el objeto completo y no solo el valor del campo que se está utilizando. La excepción es al recibir una vista, cuando solo se leerán los valores de los campos involucrados en la generación de la vista.
Las restricciones de acceso están contenidas en roles, se pueden especificar para la mayoría de los objetos de metadatos y están escritas en un lenguaje especial que es un subconjunto del lenguaje de consulta.

Idioma de restricción de acceso a datos

Las restricciones de acceso a datos se describen en un lenguaje especial, que es un subconjunto del lenguaje de consulta (descripción detallada del lenguaje de consulta. El lenguaje de restricción de acceso a datos tiene los siguientes cambios en relación con el lenguaje de consulta:
● En una solicitud de restricción de acceso a datos, siempre hay una tabla como fuente de datos: esta es la tabla del objeto al que se aplica la restricción (el objeto principal de la restricción).
● La descripción de la solicitud se ha acortado. El lenguaje de restricción de acceso a datos utiliza solo las secciones DESDE y DÓNDE del lenguaje de consulta. Entonces, la descripción del lenguaje de consulta se ve así:
SELECCIONAR [PERMITIDO] [DIFERENTE] [ PRIMERO<Количество> ]
<Lista de campos de selección>
[DE <Список источников> ]
[DÓNDE<Условие отбора> ]
[Agrupar por <Поля группировки> ]
[TENIENDO<Условие отбора> ]
[PARA CAMBIAR [ <Список таблиц верхнего уровня> ]]
Mientras que la descripción del lenguaje de consulta de restricción de acceso a datos es la siguiente:
[Alias ​​de tabla del objeto de restricción principal]
[DE <Список источников> ]
[DÓNDE<Условие отбора> ]

En las consultas anidadas utilizadas en el lenguaje de restricción de acceso a datos, el conjunto de capacidades permitidas es limitado;
● Puede especificar parámetros de sesión y opciones funcionales como elementos de condición;
● En cualquier momento de una solicitud de restricción de acceso a datos, está permitido utilizar plantillas que simplifiquen las restricciones de escritura.
La parte principal de la restricción es una condición que se evalúa para cada registro de la tabla de la base de datos que está sujeto a una restricción de acceso a los datos. Un registro se considera disponible si, como resultado de la operación de la condición para un registro de tabla del objeto principal de la restricción, se obtiene una tabla no vacía (es decir, una tabla con 1 o más registros). Si la condición da como resultado una tabla vacía, el registro para el cual se cumplió la condición de esta manera se considera inaccesible. Además, cambiar la entrada de la tabla del objeto de restricción principal
Se considera válido si el asiento no contradice la restricción especificada para el derecho, tanto antes como después de realizarse la operación de modificación.

Campos de tabla

En restricciones de acceso a datos puedes utilizar:
● Campos de tabla del objeto para el cual se describe la restricción de acceso a datos.
Por ejemplo, si se impone una restricción a la lectura de elementos del directorio de Contrapartes, entonces la restricción puede utilizar los campos del directorio de Contrapartes y sus partes tabulares. En particular, las restricciones más simples para leer elementos del directorio Contrapartes pueden verse así:

DONDE Nombre = “Fábrica de Ladrillos”
O así:

DÓNDE Productos.Nombre= “El ladrillo es rojo”
Donde Productos es la parte tabular del directorio de Contratistas.
● Campos de tablas de objetos accesibles a través de enlaces en el objeto de restricción principal.
Por ejemplo, si el atributo Administrador principal del directorio de Contratistas tiene un tipo de enlace al directorio de Usuarios, entonces la restricción de acceso puede tener, por ejemplo, la siguiente forma:

DÓNDE Código de administrador principal= “Ivánov”
O:

DÓNDE Gerente principal.Nombre.individual= “Petrovsky”
● Campos de tablas de objetos asociados al objeto principal de restricciones por determinadas condiciones y expresiones sobre los mismos.
Por ejemplo, se podrá imponer la siguiente restricción en la lectura de elementos del directorio de Contrapartes:

Contrapartes
DE
Directorio.Contrapartes CÓMO Contrapartes
CONEXIÓN IZQUIERDA Directorio.Usuarios CÓMO Usuarios
Software = Usuarios.Nombre
DÓNDE = “Petrovsky”
Esta restricción utiliza los campos de los elementos del directorio Usuarios asociados a este elemento del directorio Contrapartes por el valor de los campos Nombre.

Consultas anidadas

Las consultas anidadas se utilizan para formar conjuntos de registros que se pueden utilizar:
● vincular a la tabla del objeto de restricción principal;
● para uso como operando para operaciones de comparación B o NOT B.
Las consultas anidadas pueden utilizar cualquier característica del lenguaje de consulta excepto:
● operador EN JERARQUÍA;
● propuestas de RESULTADOS;
● los resultados de consultas anidadas no deben contener partes tabulares;
● algunas mesas virtuales, en particular Restos y pérdidas de balón.
En el siguiente ejemplo de una restricción de lectura del directorio Cuentas, se utiliza una subconsulta como un conjunto de registros para asociar con el objeto principal de la restricción:

Contrapartes
DE
Directorio.Contrapartes CÓMO Contrapartes
CONEXIÓN IZQUIERDA
(ELEGIR
Usuarios.Nombre, Usuarios.Individual
DE
Directorio.Usuarios CÓMO Usuarios
DÓNDE
Usuarios.Código> “Petechkin”) Usuarios de AS
POR Nombre de las Contrapartes. = Usuarios.Nombre
DÓNDE Usuarios.Individual.Nombre= “Petrovsky”
El siguiente ejemplo muestra una restricción en la lectura del directorio Passport Data of Individuals, en el que se utiliza una consulta anidada en
como operando de la operación de comparación B:

DÓNDE
Datos del pasaporteIndividual.Individual EN
(ELIJA VARIOS
Trabajadores.Individual COMO INDIVIDUO
DE
Registro de Información.Empleados COMO TRABAJADORES)
Si en una consulta anidada es necesario obtener datos de la parte tabular, entonces en la sección FROM de la consulta anidada debes acceder directamente a la parte tabular. Por ejemplo, en lugar de:

SELECCIONE Enlace COMO Enlace.
Productos.Nombre CÓMO Nombre del producto
DE Directorio.Contrapartes
como consulta anidada dentro de una restricción, debes usar:

Opciones de sesión

Las solicitudes de restricción de acceso a datos pueden incluir parámetros de sesión. Por ejemplo, para leer elementos del directorio. Grupos de correo electrónico Se pueden establecer las siguientes restricciones de acceso:

DÓNDE Propietario.AccountAccess.User = & Usuario actual
Y Propietario.Acceso a cuenta.Administración= VERDADERO

CurrentUser es un parámetro de sesión

Opciones funcionales

Las solicitudes de restricción de acceso a datos pueden incluir opciones funcionales. Sólo se pueden utilizar opciones funcionales independientes de los parámetros. Por ejemplo, si el directorio de Artículos tiene el atributo MainWarehouse, entonces la restricción para leer este atributo puede verse así:

DONDE &Contabilidad de almacén = VERDADERO

Donde la Contabilidad de Almacén es una opción funcional

Características de uso

No todos los campos del objeto de datos de restricción principal pueden usarse en restricciones sobre los siguientes tipos de objetos de base de datos:
● en los registros de acumulación, las restricciones de acceso sólo pueden contener medidas del objeto principal de la restricción;
● en los registros contables, sólo se pueden utilizar en las restricciones las mediciones del balance del objeto principal de la restricción.
NOTA. Si, en condiciones de acceso limitado a los datos del registro de acumulación de facturación, se utilizan mediciones que no están incluidas en los totales, entonces
Al acceder a la tabla virtual de revoluciones no se utilizan los totales almacenados y la solicitud se realiza íntegramente según la tabla de movimientos.

Acciones de restricción de acceso

Las restricciones de acceso se verifican cada vez que se realizan operaciones apropiadas en los objetos de la base de datos (desde cuadros de diálogo, desde el lenguaje integrado, mediante consultas) y pueden actuar de dos maneras:
● Todo. El método "todos" implica que se debe realizar alguna operación sobre los datos (desde cuadros de diálogo, desde un lenguaje integrado o mediante consultas) en todos los objetos de la base de datos implicados en esta operación. Si dicha operación requiere leer o modificar objetos de la base de datos para los cuales no se cumplen las restricciones de acceso apropiadas, la operación finaliza
anormal debido a una infracción de acceso.
● Permitido. El método "permitido" implica que al realizar una operación con datos, solo se deben leer aquellos objetos de la base de datos que cumplan con las restricciones de acceso apropiadas. Los objetos de la base de datos que no cumplen con las restricciones de acceso se consideran faltantes al realizar dicha operación y no afectan el resultado de la operación.
Las restricciones de acceso a los datos se imponen a los objetos de la base de datos en el momento en que 1C:Enterprise accede a la base de datos. En la versión cliente-servidor de 1C:Enterprise, las restricciones se aplican en el servidor 1C:Enterprise.
El método de operación de las restricciones elegidas para realizar cada operación sobre datos está determinado por el propósito de esta operación y el grado de responsabilidad de sus resultados. En particular, el método "permitido" se utiliza cuando se muestran listas dinámicas y algunas otras acciones interactivas. El método "todos" se utiliza al realizar cualquier operación con objetos de la aplicación desde el lenguaje integrado 1C:Enterprise, incluidos los cambios en los objetos de la base de datos. Por lo tanto, por ejemplo, pueden surgir dificultades al construir una selección para el método Select() de administradores de directorios, documentos y otros, con posterior omisión del resultado, si se establece una restricción bastante compleja en el objeto correspondiente, ya que no todas las condiciones en el La restricción de los derechos de acceso se puede representar adecuadamente como una selección para el método Select().
En consultas, puede controlar cómo operan las restricciones de acceso a datos. Para ello, el lenguaje de consulta proporciona una palabra clave. PERMITIDO. Si la solicitud no especifica PERMITIDO, entonces las restricciones se aplican en la forma "todos". Si se especifica la palabra PERMITIDO, entonces se selecciona el método "permitido".
Es importante que si una consulta no especifica la palabra clave ALLOWED, todas las selecciones especificadas en esa consulta no deben entrar en conflicto con ninguna de las restricciones de lectura de los objetos de la base de datos utilizados en la consulta. Además, si la consulta utiliza tablas virtuales, las selecciones correspondientes deben aplicarse a las propias tablas virtuales.
Ejemplo:

ELEGIR
Información de contactoSecciónPrimera.Introducción
DE RegisterInformation.ContactInformation.SliceLast(, Tipo = &Tipo)
CÓMO ContactoInformaciónSliceFirst
DÓNDE
ContactInformationSliceFirst.Type = &Tipo
Cuando se utiliza tecnología de objetos, no se admite el acceso a datos en modo PERMITIDO. Se supone que la tecnología de objetos se utiliza para las operaciones más críticas con datos, incluido su cambio. Para obtener todos los datos utilizando tecnología de objetos, independientemente de las restricciones establecidas, puede realizar las acciones necesarias en un módulo privilegiado o en nombre de un usuario con todos los derechos. En la tecnología de objetos no existen medios para obtener únicamente datos permitidos.

Mecanismo para imponer restricciones.

Cualquier operación con datos almacenados en una base de datos en 1C:Enterprise conduce en última instancia al acceso a la base de datos con algunos
Solicitud de lectura o cambio de datos. En el proceso de ejecución de consultas a la base de datos, los mecanismos internos de 1C:Enterprise imponen restricciones de acceso. En este caso:
● Se genera una lista de derechos (leer, agregar, cambiar, eliminar), una lista de tablas de la base de datos y una lista de campos utilizados por esta solicitud.
● De todos los roles del usuario actual, se seleccionan restricciones de acceso a datos para todos los derechos, tablas y campos involucrados en la solicitud. Además, si un rol no contiene restricciones de acceso a los datos de una tabla o campo, esto significa que los valores de los campos obligatorios de cualquier registro están disponibles en esta tabla. En otras palabras, la ausencia de restricciones de acceso a los datos significa la presencia de restricciones.
DÓNDE está la Verdad.
● Recupera los valores actuales de todos los parámetros de sesión y opciones funcionales involucradas en las restricciones seleccionadas.
Para obtener el valor de un parámetro de sesión, el usuario actual no necesita tener permiso para obtener ese valor. Sin embargo, si no se ha establecido el valor de algún parámetro de sesión, se producirá un error y no se ejecutará la consulta de la base de datos.
La recepción de opciones funcionales está influenciada por la propiedad Modo privilegiado al recibir la opción funcional.
Si se borra esta propiedad, entonces el usuario actual debe tener acceso de lectura al objeto en el que está almacenada la opción de función.
● Las restricciones derivadas de un rol se combinan mediante la operación AND.
● Las restricciones derivadas de diferentes roles se combinan mediante una operación OR.
● Las condiciones construidas se añaden a las consultas SQL con las que 1C:Enterprise accede al DBMS. Al acceder a datos desde condiciones de restricción de acceso, no se realiza la verificación de derechos (ni para objetos de metadatos ni para objetos de base de datos). Además, el mecanismo para agregar condiciones depende del método seleccionado para operar las restricciones "todas" o "permitidas".
Método "todo"
Al imponer restricciones utilizando el método "todos", se agregan condiciones y campos a las consultas SQL para que 1C:Enterprise pueda obtener información sobre si, durante la ejecución de una consulta a la base de datos, se utilizaron o no datos prohibidos para un usuario determinado. Si se utilizaron datos prohibidos, la solicitud fallará. La imposición de restricciones de acceso utilizando el método "todos" se presenta esquemáticamente en la Fig. 1:

Arroz. 1. Método "Todo"

Método "permitido"
Al aplicar restricciones utilizando el método "permitido", se agregan condiciones a las consultas SQL para que los registros prohibidos para el usuario actual no afecten el resultado de la consulta. En otras palabras, cuando se imponen restricciones en el modo "permitido", los registros prohibidos para un usuario determinado se consideran faltantes, lo cual se presenta esquemáticamente en la Fig. 3.

Otros objetos relacionados con restricciones de acceso a datos

Al diseñar configuraciones que utilizan restricciones de acceso a datos, los objetos de metadatos, como parámetros de sesión, opciones funcionales y módulos compartidos con un indicador Privilegiado, pueden resultar útiles.
Opciones de sesión
Los parámetros de sesión se pueden usar en restricciones de acceso a datos de la misma manera que los parámetros de solicitud se pueden usar en una solicitud.
Opciones funcionales
Las opciones funcionales independientes de los parámetros se pueden usar en las restricciones de acceso a datos de la misma manera que los parámetros de consulta se pueden usar en una consulta.
Módulos comunes privilegiados

Si se selecciona el indicador Privilegiado para un módulo común, entonces la ejecución de los procedimientos y funciones de este módulo adquiere detalles importantes:
● En la versión cliente-servidor de 1C:Enterprise, sólo se puede privilegiar el módulo que se ejecuta en el servidor.
● La ejecución de procedimientos y funciones del módulo privilegiado y todo lo que se llama desde ellos se realiza cuando el sistema de restricción está apagado.
derechos tanto sobre objetos de metadatos como sobre datos. Así, desde un módulo privilegiado se puede realizar cualquier operación sobre
cualquier objeto, incluso si el usuario actual no tiene los derechos adecuados.
Los módulos privilegiados están diseñados para establecer inicialmente los valores de los parámetros de sesión utilizados en las restricciones de acceso a datos.
Se pueden utilizar módulos más generales para algunas acciones holísticas sobre datos por parte de un usuario con derechos limitados.
Por ejemplo, si las funciones del usuario incluyen ingresar y publicar documentos, pero el usuario no debe tener acceso a los datos que se ven afectados por la publicación de documentos, entonces la ejecución de la operación de publicación se puede mover a un módulo privilegiado. Esto permitirá al usuario publicar documentos sin otorgarle derechos sobre otra información (registros, por ejemplo).
Modo privilegiado
Es posible instalar mediante programación un modo privilegiado cuando se trabaja con datos. Configurar el modo privilegiado mediante programación
Puede ser necesario en el caso de operaciones masivas con datos de bases de datos, y no tiene sentido verificar los derechos de acceso a los datos.
Para obtener una descripción del modo privilegiado, consulte aquí.

Usando el preprocesador

Al editar el texto de las restricciones de acceso a los datos, es posible utilizar instrucciones del preprocesador. Las siguientes instrucciones están disponibles:

#SI<Выражение>#ENTONCES
#ELSEIF<Выражение>#ENTONCES
#DE LO CONTRARIO
#ENDSIF
<Выражение>– una expresión lógica arbitraria en el lenguaje incorporado, cuyo resultado es de tipo booleano. La expresión puede contener:
● operaciones de comparación<, >, <=, >= , =, <> ;
● operaciones lógicas Y, O, NO;
● parámetros de sesión: se utiliza la sintaxis &Parámetro, donde Parámetro es el nombre del parámetro de sesión.
Si el resultado de la expresión de la declaración #IF o #ELSEIF es Verdadero, entonces el texto resultante de la declaración de restricción de acceso contiene el texto ubicado después de la palabra clave #THEN. Si el resultado de la expresión es Falso, entonces el texto ubicado después de la palabra clave #THEN no se coloca en el texto de la declaración de restricción de acceso. El texto que sigue a la declaración #ELSE se colocará en el texto de restricción de acceso resultante si no se cumple ninguna de las condiciones anteriores.
NOTA. Si el texto de una restricción de acceso a datos contiene instrucciones del preprocesador, dicha restricción no pasa la verificación de sintaxis durante la edición y no se puede cambiar utilizando el constructor.
Ejemplo:

#SI y usuario actual<>“Klimova” #ENTONCES
<текст ограничения доступа>
#ENDSIF
Aquí Usuario actual– tipo de parámetro de sesión DirectoryLink.Usuarios.
Este diseño significa que la condición para establecer una restricción de acceso se verificará para todos los usuarios del directorio, excepto para el usuario Klimova.

Plantillas de texto de restricción de acceso

Un rol puede contener una lista de plantillas de restricción de acceso, que se describen en la pestaña Plantillas de restricción del formulario del rol. También puede editar plantillas de restricción de acceso en el editor para la edición grupal de plantillas y restricciones de acceso.
Cada plantilla de restricción de acceso tiene un nombre y un texto. El nombre de la plantilla sigue las reglas habituales para los nombres adoptados en el sistema 1C:Enterprise.
El texto de la plantilla contiene parte del texto en el lenguaje de restricción de acceso a datos y puede contener parámetros que se resaltan con el símbolo
“#”.
Después del símbolo “#” puede seguir:
● Una de las palabras clave:
● Parámetro seguido del número del parámetro en la plantilla entre paréntesis;
● CurrentTable – indica la inserción en el texto del nombre completo de la tabla para la cual se está creando la restricción;
● Nombre de la tabla actual– indica la inserción en el texto del nombre completo de la tabla (como un valor de cadena, entre comillas) a la que se aplica la instrucción, en la versión actual del lenguaje integrado;
●Nombre del derecho de acceso actual: contiene el nombre del derecho al que se aplica la restricción actual: LEER/AÑADIR/INSERTAR/CAMBIAR/
ACTUALIZAR, ELIMINAR;
● nombre del parámetro de plantilla: significa la inserción de la restricción del parámetro de plantilla correspondiente en el texto;
● Símbolo “#”: indica la inserción de un símbolo “#” en el texto.

Una expresión de restricción de acceso puede contener:

● Plantilla de restricción de acceso, que se especifica en el formato
#TemplateName(“Valor del parámetro de plantilla 1”, “Valor del parámetro de plantilla 2”, ...). Cada parámetro de plantilla está entre comillas dobles. Si necesita especificar un carácter de comilla doble en el texto del parámetro, debe utilizar dos comillas dobles.
● Función La página contiene (dónde buscamos, qué buscamos). La función está diseñada para buscar una aparición de la cadena WhatWeLook en la cadena WhereWeLook. Devuelve True si se encuentra la ocurrencia y False en caso contrario.

● El operador + para la concatenación de cadenas.
Para facilitar la edición del texto de la plantilla, en la pestaña Plantillas de restricción en el formulario de rol, haga clic en el botón Establecer texto de plantilla. En el cuadro de diálogo que se abre, ingrese el texto de la plantilla y haga clic en Aceptar.
El sistema 1C:Enterprise verifica la sintaxis de los textos de las plantillas, verifica la sintaxis del uso de las plantillas y realiza macrosustituciones de los textos de las plantillas de restricción de acceso a funciones en el texto de la solicitud.
La sustitución de plantillas de macros es:
● reemplazar apariciones de parámetros en el texto de la plantilla con valores de parámetros de la expresión para usar la plantilla en el texto de la restricción;
● reemplazar la expresión de uso de la plantilla en el texto de la solicitud con el texto de la plantilla resultante.
Cuando llama al constructor de consultas para una condición que contiene plantillas de restricción de acceso, se emite una advertencia de que se reemplazarán todas las plantillas.
Los siguientes son ejemplos de plantillas de restricciones:

Para administrar de manera flexible el acceso de los usuarios a los datos de acuerdo con la funcionalidad al configurar restricciones de acceso a los datos, se recomienda
adherirse a los siguientes principios:
● Es necesario seleccionar un conjunto de información (puede depender del usuario actual) para el cual sea adecuada una preparación preliminar. La información seleccionada debería, por un lado, simplificar al máximo las restricciones de acceso a los datos y, por otro lado, no debería ser demasiado amplia. Distribuirlo según los parámetros de la sesión.
● Establecer los valores de los parámetros de sesión en el controlador SetSessionParameters() del módulo de sesión.
● Establecer restricciones de acceso a aquellos datos para los que esté justificado (los datos son secretos o más importantes para mantener la integridad del sistema). Tenga en cuenta que establecer restricciones de acceso puede ralentizar el acceso a estos datos. Las restricciones demasiado complejas también pueden provocar desaceleraciones.
● Si es necesario garantizar que un cierto número limitado de operaciones con datos sea realizado por un usuario al que no es práctico darle acceso completo a estos datos, mueva estas acciones a módulos privilegiados o habilite y deshabilite explícitamente el modo privilegiado en lugares apropiados en el código del programa.
● El acceso a datos para diversas comprobaciones realizadas por el sistema cuando se escriben objetos se realiza en modo privilegiado.

Esto le permite no deshabilitar las restricciones de permisos a nivel de registro para los campos correspondientes si la configuración funciona con estos datos.
planificado sólo en modo controlado:

● para directorios al verificar el padre, el propietario y la unicidad del código;
● para documentos, procesos comerciales y tareas al verificar la unicidad del número;
● deshabilitado para planes de intercambio al verificar la unicidad del código;
● para planes de cuentas y planes de tipos de características al comprobar el padre y la unicidad del código.

Existen algunas limitaciones y consideraciones que se deben tener en cuenta al crear una consulta de restricción de datos:

● Si se especifican restricciones de acceso a datos para una tabla de objetos y se utiliza una combinación con dicha tabla en la consulta de datos, entonces en la condición de conexión (sección de solicitud de software) se permite el uso de la parte tabular del objeto con la restricción de acceso especificada. no permitido.
● Si una consulta especifica una tabla para la cual no se utilizan campos en la consulta, todas las restricciones de acceso a los datos se imponen en esta tabla. Por ejemplo, solicitar SELECCIONE CANTIDAD(*) DEL Directorio.Contrapartes se ejecutará teniendo en cuenta todas las restricciones de acceso especificadas para el directorio de prueba. Las restricciones las impone “OR”. Esto significa que todos los registros que estén disponibles bajo al menos una condición estarán disponibles. Si no se especifican condiciones para algunos campos, la consulta se ejecutará para todos los registros de la tabla.
Si la consulta utiliza una tabla de nivel superior, no se imponen las restricciones especificadas para las columnas de las tablas anidadas.
Si una consulta utiliza una tabla anidada, se aplican restricciones tanto a la tabla anidada como a la tabla de nivel superior.
Por ejemplo, solicitar SELECCIONE CANTIDAD(*) DEL Directorio.Contrapartes.Acuerdos se ejecutará teniendo en cuenta todas las restricciones para el directorio de Contrapartes, así como teniendo en cuenta las restricciones relacionadas con la parte tabular del Acuerdo.

● Si las restricciones de acceso deniegan el acceso a los campos necesarios para obtener una representación del objeto de metadatos de referencia.
Si se deniegan los datos o el acceso al objeto en el nivel de derechos de acceso, la obtención de una representación de dicho objeto no afecta el progreso de la transacción actual.

Constructor de restricción de acceso a datos

Para llamar al constructor en el campo de la tabla Restricciones de acceso a datos en la columna Restricciones de acceso, debe ir al modo de edición y
Haga clic en el botón Seleccionar y, en el formulario que se abre, haga clic en el botón Generador de consultas….
El formulario del constructor se muestra en la pantalla:

Arroz. 3. Pestaña “Tablas y campos” del diseñador de restricciones

Con su ayuda, se crean las condiciones para establecer restricciones de acceso a datos.
En la pestaña Tablas y campos, seleccione los objetos requeridos en la lista Base de datos y muévalos a la lista Tablas. Si se especifican varias tablas, la pestaña Enlaces se agrega al formulario del diseñador.

Arroz. 4. Pestaña “Enlaces” del diseñador de restricciones

En la pestaña Enlaces, se forman condiciones que se imponen a los enlaces entre los campos de la tabla. Para ingresar una nueva condición, haga clic en el botón Agregar y seleccione una de las tablas en la columna Tabla1. En la columna Tabla2, seleccione la tabla cuyos campos están relacionados con los campos de la primera. Debajo de la lista de condiciones hay controles que se pueden usar para crear una condición para vincular tablas.
Si se selecciona un tipo de condición simple, en Campo1 y Campo2 se seleccionan los campos relacionados de las tablas especificadas y se establece la condición de comparación. Si se seleccionan campos que no se comparan, entonces en la línea de la lista de condiciones en la columna Condición de enlace se muestra el texto: Condición llena incorrectamente.
En la pestaña Condiciones, si es necesario, debe especificar las condiciones según las cuales se seleccionarán los datos de origen.

Arroz. 5. Pestaña “Condiciones” del diseñador de restricciones

Para cada campo seleccionado, debe seleccionar el tipo de condición y especificar el nombre del parámetro. El parámetro de sesión se puede utilizar como parámetro. Se permiten múltiples condiciones. En este caso, en la columna Condición del campo de la tabla de condiciones, el texto de la condición se muestra en varias líneas.
En cualquier momento durante la creación de una solicitud, el texto de la solicitud se puede ver haciendo clic en el botón Solicitar.

Edición por lotes de restricciones de permisos y plantillas.

El modo para la edición grupal de restricciones de derechos de acceso y plantillas se llama mediante el comando Todas las restricciones de acceso del menú contextual de la rama Roles. El formulario que se abre contiene dos pestañas: Restricciones de acceso y Plantillas de restricciones.

Arroz. 6 Todas las restricciones de permisos y plantillas.

en el marcador Restricciones de acceso Puede ver todas las restricciones de acceso ingresadas en una lista general (para todos los roles, objetos, derechos, combinaciones de campos).
Es posible agregar restricciones de acceso para varios roles, objetos, derechos y combinaciones de roles a la vez.
Puede filtrar la lista según varios criterios.

Arroz. 7. Seleccionar restricciones de acceso

El modo de edición de grupo le permite eliminar las restricciones seleccionadas en la lista.
Es posible editar las restricciones seleccionadas. En este caso, podrá cambiar la composición de los campos y/o las restricciones de acceso.
El modo de edición de grupo también le permite copiar restricciones seleccionadas a otros roles.

en el marcador Plantillas de restricciones puede ver todas las plantillas de restricción de acceso presentes en la solución de la aplicación, mientras que desde el texto de la plantilla en sí, solo se muestran las primeras 10 líneas en la tabla, que terminan con el símbolo “…” si el texto de la plantilla tiene más de 10 líneas. La ventana de edición de la plantilla mostrará el texto completo de la plantilla.

Fig 8. Todas las plantillas de restricción de acceso

Es posible agregar una plantilla de restricción de acceso para varios roles a la vez.

Todas las configuraciones de derechos de usuario que realizaremos en el marco de este artículo se encuentran en la sección 1C 8.3 "Administración" - "Configuración de usuarios y derechos". Este algoritmo es similar en la mayoría de las configuraciones de formularios administrados. El programa 1C Accounting se utilizará como ejemplo, pero la configuración de derechos en otros programas (1C UT 11, 1C ZUP 3, 1C ERP) se realiza exactamente de la misma manera.

Vayamos a la sección "Usuarios" de la ventana de configuración. Aquí vemos dos hipervínculos: "Usuarios" y "Configuración de inicio de sesión". El primero de ellos permite acceder directamente al listado de usuarios de esta base de información. Antes de crear un nuevo usuario, veamos las posibles configuraciones de inicio de sesión (hipervínculo a la derecha).

En este formulario de configuración, puede configurar la complejidad de la contraseña (al menos 7 caracteres, contenido obligatorio de varios tipos de caracteres, etc.). También puede especificar la longitud de la contraseña, su período de validez y prohibir a los usuarios iniciar sesión en el programa si no han estado activos durante un período de tiempo determinado.

Ahora puede proceder directamente a agregar un nuevo usuario a 1C. Esto se puede hacer haciendo clic en el botón "Crear", como se muestra en la imagen a continuación.

En primer lugar, indicaremos el nombre completo: "Dmitry Petrovich Antonov" y seleccionaremos una persona del directorio correspondiente. Aquí también podrá indicar el departamento en el que trabaja nuestro empleado.

El nombre de usuario "AntonovDP" se sustituyó automáticamente como abreviatura del nombre completo "Dmitry Petrovich Antonov". Configuremos una contraseña y autenticación 1C Enterprise. Aquí también podrás indicar si este usuario puede cambiar su contraseña de forma independiente.

Digamos que queremos que Dmitry Petrovich Antonov esté disponible en la lista de selección al iniciar esta base de información. Para hacer esto, debe marcar la casilla de verificación en el elemento "Mostrar en la lista de selección". Como resultado, la ventana de autorización al iniciar el programa se verá como se muestra en la siguiente figura.

Prestemos atención a otra configuración importante en la tarjeta del directorio de usuarios: "Se permite iniciar sesión en el programa". Si no se establece el retraso, el usuario simplemente no podrá ingresar a esta base de información.

Derechos de acceso

Después de completar todos los datos en la tarjeta de usuario, Dmitry Petrovich Antonov, los anotaremos y procederemos a configurar los derechos de acceso, como se muestra en la siguiente figura.

Se abrió ante nosotros una lista de perfiles de acceso previamente ingresados ​​en el programa. Marque las casillas que sean obligatorias.

Acceder a perfiles de grupo

Los perfiles de grupo de acceso se pueden configurar desde el formulario principal de configuración de usuarios y derechos. Vaya a la sección "Grupos de acceso" y haga clic en el hipervínculo "Perfiles de grupos de acceso".

Creemos un nuevo grupo a partir del formulario de lista que se abre. En la sección tabular de la pestaña “Acciones permitidas (roles)”, marque las casillas de aquellos roles que afectarán los derechos de acceso de los usuarios incluidos en el grupo que estamos creando. Todos estos roles se crean y configuran en el configurador. No se pueden cambiar ni crear nuevos desde el modo usuario. Sólo puedes elegir de la lista existente.

RLS: Restricción de acceso a nivel de registro

Le permite configurar de manera más flexible el acceso a los datos del programa en ciertas áreas. Para activarlo, marque la casilla del mismo nombre en el formulario de configuración de usuarios y derechos.

Tenga en cuenta que habilitar esta configuración puede afectar negativamente el rendimiento del sistema. La cuestión es que el mecanismo RLS modifica todas las solicitudes en función de las restricciones establecidas.

Vayamos al perfil del grupo de acceso "Grupo de prueba" que creamos anteriormente. La siguiente figura muestra que después de habilitar las restricciones de acceso a nivel de registro, apareció una pestaña adicional de "Restricciones de acceso".

Digamos que queremos que los usuarios asignados a un grupo de prueba tengan acceso a los datos de todas las organizaciones en esta base de información, excepto aquellas especificadas en el perfil.

En la parte tabular superior estableceremos las restricciones de acceso por organización. En la parte inferior aclararemos que no se proporcionará acceso a los datos (documentos, directorios, etc.) a la organización “Roga LLC”.

El objeto de configuración "rol" otorga un conjunto de derechos para operaciones (acciones) sobre los objetos de configuración.

Rol "Plenos derechos".

Este es solo un rol (no predefinido) en el que se verifican todos los tipos de derechos sobre todos los objetos de configuración.

Lo que lo distingue de otras funciones es la presencia del derecho de “Administración”.

Si se crea al menos un usuario, el sistema comienza a verificar la presencia del derecho "Administración"; al menos un usuario debe tenerlo.

Restricciones de acceso a nivel de registro

Seguridad de nivel de fila (RLS): restricción a nivel de registro.

El mecanismo de restricción de acceso a datos le permite administrar los derechos de acceso no solo a nivel de objetos de metadatos, sino también a nivel de objetos de base de datos. Los siguientes objetos se pueden utilizar para restringir el acceso a los datos:

• roles,
• parámetros de sesión,
• opciones funcionales,
• módulos compartidos privilegiados,
• palabra clave PERMITIDA en el lenguaje de consulta.

El mecanismo está diseñado para restringir el acceso a los registros de la tabla de objetos de metadatos en función de condiciones arbitrarias impuestas a los valores de los campos de fila de estas tablas. Por ejemplo, para ver registros sólo de “sus” contrapartes, organizaciones, etc.

Implementación técnica de restricciones de acceso en 1C.

1C genera una solicitud al DBMS. El clúster de servidores agrega una sección DONDE a la solicitud, que contiene el texto de la condición para restringir el acceso a través de RLS, luego esta solicitud se envía al DBMS y los datos extraídos se devuelven al cliente 1C.

Este mecanismo funcionará para cualquier solicitud del cliente:

• en informes,
• en listas dinámicas y en formularios de lista regulares
• en consultas personalizadas.

Esta implementación del mecanismo afecta en gran medida el rendimiento.

Formas de eludir las restricciones de acceso.

En operaciones grandes que consumen muchos recursos (procesamiento de reenvío de documentos, por ejemplo), parte del código se puede mover a módulos privilegiados.

A) Módulo privilegiado es un módulo común con el indicador "Privilegiado" en las propiedades.

Su peculiaridad es que el código que contiene se ejecuta sin ningún control de derechos de acceso, incluido RLS.

B) También privilegiado el modo se puede activar para módulos de objetos de documento. Esto se hace en las propiedades del documento, bandera

• Trato privilegiado a la hora de realizar
• Modo privilegiado al cancelar una transacción

B) Método Establecer modo privilegiado()

El comando del sistema le permite privilegiar parte del código de cualquier módulo.

A partir de la siguiente línea de código, funcionará el modo de ejecución privilegiado.

Operará hasta la línea para deshabilitar este modo o hasta el final del procedimiento/función.

(Verdadero);

// cualquier código aquí se ejecutará sin control de derechos y RLS

Establecer modo privilegiado(Mentir ); // o fin del procedimiento/función

La cantidad de veces que se habilita el modo privilegiado debe coincidir con la cantidad de veces que se deshabilita. Sin embargo, si dentro de un procedimiento o función se activó el modo privilegiado (una o más veces), pero no se desactivó, entonces el sistema se apagará automáticamente tantas veces como encendidos incompletos hubo en el procedimiento o función que se dejó.

Si en un procedimiento o función llama a un método Establecer modo privilegiado(Falso) hizo más que llamadas a métodos Establecer modo privilegiado(Verdadero), entonces se lanzará una excepción.

Función Modo privilegiado() devuelve Verdadero si el modo privilegiado todavía está habilitado y Falso si está completamente deshabilitado. Esto no analiza la cantidad de configuraciones de modo privilegiado en una función particular.

Todos los procedimientos y funciones llamados también se ejecutarán en modo privilegiado.

También es posible iniciar una sesión privilegiada. Esta es una sesión en la que el modo privilegiado se establece desde el inicio del sistema. Además, durante la operación el método Modo privilegiado() siempre devolverá Verdadero y no se admite la capacidad de deshabilitar el modo privilegiado. Sólo un usuario que tenga derechos administrativos (derecho de administración) puede iniciar una sesión privilegiada. La sesión se puede iniciar utilizando el modificador de línea de comando de inicio de la aplicación cliente UsePrivilegedMode o el parámetro de cadena de conexión de la base de información prmod.

Naturalmente surge la pregunta: ¿Por qué establecer restricciones de acceso si se pueden eludir tan fácilmente?

Modo seguro.

Sí, puede escribir procesamiento externo con un modo de ejecución privilegiado y descargar/corromper datos. Para evitar esto, el sistema tiene un método de contexto global.

Establecer modo seguro().

El modo seguro, entre otras cosas, ignora el modo privilegiado.

Debe instalarse antes de llamar mediante programación a procesadores externos o exportar procedimientos y funciones desde sus módulos.

Al realizar operaciones prohibidas, se genera una excepción en tiempo de ejecución.

Además, en el nivel de configuración de funciones, puede desactivar la capacidad de los usuarios de iniciar interactivamente informes y procesamientos externos.

Configurar restricciones de acceso

RLS solo se puede configurar para derechos:

• leer (seleccionar)
• añadiendo (insertar)
• cambiar (actualizar)
• borrar

Para operaciones de lectura y eliminación, un objeto que reside en la base de datos debe cumplir con las restricciones de acceso a los datos.

Para la operación de agregar La restricción de acceso a los datos debe corresponder al objeto que se planea escribir en la base de datos.

Para operación de cambio la restricción de acceso a datos debe cumplir con el objeto tanto antes del cambio (para que el objeto se lea) como después del cambio (para que el objeto se escriba).

Para todos los demás derechos no existe tal opción.

Agreguemos una nueva restricción para el derecho de "lectura" del directorio "Nomenclatura". Se abrirá una lista de campos para los cuales puede configurar la restricción agregada.

Esto significa que si intenta acceder a campos marcados, se activará la restricción, pero si intenta acceder a campos no marcados, la restricción no se activará.

Si seleccionas la bandera " Otros campos", la restricción se configurará para todos los campos de la tabla, excepto para los campos para los cuales las restricciones están establecidas explícitamente.

*Característica: para derechos de agregar, cambiar y eliminar:

• La restricción solo se puede configurar para todos los campos.
• Sólo puede haber una restricción.

Para el derecho “Leer”, puedes configurar varias condiciones que se combinarán con el operador lógico “Y”.

No todos los campos del objeto de datos de restricción principal pueden usarse en restricciones sobre los siguientes tipos de objetos de base de datos:

• en los registros de acumulación, las restricciones de acceso sólo pueden contener medidas del objeto principal de la restricción;
• en los registros contables, las restricciones solo pueden utilizar mediciones del balance del objeto principal de la restricción

Si, en condiciones de acceso limitado a los datos del registro de acumulación circulante, se utilizan mediciones que no están incluidas en los totales, entonces al acceder a la tabla virtual de revoluciones no se utilizan los totales almacenados y la solicitud se realiza íntegramente de acuerdo con la mesa de movimiento.

Mecanismo de imposición de restricciones de acceso.

Cualquier operación con datos almacenados en una base de datos en 1C:Enterprise conduce en última instancia a una llamada a la base de datos con alguna solicitud para leer o cambiar los datos. En el proceso de ejecución de consultas a la base de datos, los mecanismos internos de 1C:Enterprise imponen restricciones de acceso. En este caso:

• Se genera una lista de derechos.(leer, agregar, modificar, eliminar), una lista de tablas de bases de datos y una lista de campos utilizados por esta consulta.
• De todos los roles del usuario actual Se seleccionan restricciones de acceso. a los datos de todos los derechos, tablas y campos involucrados en la solicitud. Además, si un rol no contiene restricciones de acceso a los datos de una tabla o campo, esto significa que los valores de los campos obligatorios de cualquier registro están disponibles en esta tabla. En otras palabras, la ausencia de una restricción de acceso a los datos significa la presencia de una restricción DONDE ES VERDAD.
• Recupera los valores actuales de todos los parámetros de sesión y opciones funcionales. participando en las restricciones seleccionadas.

Para obtener el valor de un parámetro de sesión u opción de característica, el usuario actual no necesita tener permiso para obtener ese valor. Sin embargo, si no se ha establecido el valor de algún parámetro de sesión, se producirá un error y no se ejecutará la consulta de la base de datos.

Las restricciones derivadas de un rol se combinan mediante la operación AND.

Las restricciones derivadas de diferentes roles se combinan mediante la operación OR.

Las condiciones construidas se agregan a las consultas SQL con las que 1C: Enterprise accede al DBMS. Al acceder a datos desde condiciones de restricción de acceso, no se realiza la verificación de derechos (ni para objetos de metadatos ni para objetos de base de datos). Además, el mecanismo para agregar condiciones depende del método seleccionado para operar las restricciones "todas" o "permitidas".

*Característica: Si un usuario tiene acceso a varios roles con restricciones configuradas en el nivel de registro para un objeto, entonces, en este caso, las condiciones de las restricciones se agregan mediante la operación lógica "O". En otras palabras, los poderes del usuario son acumulativos.

Esto lleva a la siguiente conclusión: no permita que las condiciones para restringir el acceso a un objeto en diferentes roles se crucen, ya que en este caso el texto de la solicitud será muy complicado y esto afectará el rendimiento.

Método "todo".

Al imponer restricciones utilizando el método "todos", se agregan condiciones y campos a las consultas SQL para que 1C:Enterprise pueda obtener información sobre si, durante la ejecución de una consulta a la base de datos, se utilizaron o no datos prohibidos para un usuario determinado. Si se utilizaron datos prohibidos, la solicitud fallará debido a una infracción de acceso.

La imposición de restricciones de acceso utilizando el método "todos" se presenta esquemáticamente en la figura:

Método “permitido”.

Al aplicar restricciones utilizando el método "permitido", se agregan condiciones a las consultas SQL para que los registros prohibidos para el usuario actual no afecten el resultado de la consulta. En otras palabras, cuando se imponen restricciones en el modo "permitido", los registros prohibidos para un usuario determinado se consideran faltantes y no afectan el resultado de la operación, que se presenta esquemáticamente en la figura:

Las restricciones de acceso a los datos se imponen a los objetos de la base de datos en el momento en que 1C:Enterprise accede a la base de datos.

En la versión cliente-servidor de 1C:Enterprise, las restricciones se aplican en el servidor 1C:Enterprise.

Sin embargo, esta opción (PERMITIDO) no funcionará si en una consulta hacemos referencia a una tabla para la que no están configuradas restricciones de acceso, pero que contiene referencias a filas de la tabla con restricciones configuradas. En este caso, el resultado de la consulta mostrará "<Объект не найден>........." en lugar del valor del campo de referencia.

Si está desarrollando un informe o procesándolo utilizando consultas de configuración estándar o personalizadas, siempre marque la bandera "Permitido" para que el informe funcione bajo cualquier usuario con cualquier conjunto de derechos.

En el caso de que un objeto lea datos de la base de datos, no es posible establecer el indicador "Permitido". Por lo tanto es necesario configurar selecciones para la lectura de objetos, teniendo en cuenta posibles restricciones de derechos de acceso para el usuario. En la tecnología de objetos no existen medios para obtener únicamente datos permitidos.

Es importante que si una consulta no especifica la palabra clave ALLOWED, todas las selecciones especificadas en esa consulta no deben entrar en conflicto con ninguna de las restricciones de lectura de los objetos de la base de datos utilizados en la consulta. Además, si la consulta utiliza tablas virtuales, las selecciones correspondientes deben aplicarse a las propias tablas virtuales.

Práctica 1. Generador de consultas en la configuración de RLS.

Compongamos el texto de la sección "DÓNDE" en la consulta al directorio. Puede utilizar el generador de consultas.
El diseñador tiene una apariencia minimalista.

Pestaña “Tablas”

La tabla principal será la tabla del objeto para el cual se está configurando la restricción.

También puede seleccionar otras tablas y configurar varias conexiones entre ellas en la pestaña "Relaciones".

Pestaña "Condiciones"

Aquí puede configurar las condiciones reales de restricción de acceso.

Agreguemos condiciones al atributo "Precio" del directorio de nomenclatura para tener derecho a "leer" todos los campos de la tabla.

“Nomenclatura DONDE Nomenclatura.Precio > 500”

Veamos cómo funciona esta sencilla regla. La tabla de directorio contiene los siguientes elementos:

Después de configurar una restricción de acceso, la tabla mostrará solo los elementos que cumplan la condición:

Los grupos también desaparecieron. Cambiemos el texto de la restricción.

“Nomenclatura DONDE Nomenclatura.Precio > 500

O Nomenclatura. Este es un grupo"

Bueno, eso es lo que necesitas.

Si elimina la visualización del campo "código" en la configuración de la lista, se mostrarán todos los elementos del directorio, es decir. la restricción no funcionó. Si configura el campo "Código" para que se muestre, la restricción funcionará.

En este caso, a pesar de que el elemento del directorio está visible en el campo de lista, su formulario no se puede abrir porque está configurada una restricción en el atributo. Lo mismo sucede en una solicitud arbitraria: cuando intentas obtener una propiedad “restringida”, habrá un error de acceso.

Si intenta obtener las credenciales "restringidas" mediante programación, también se generará un error de acceso.

Además, no será posible acceder a ningún campo de un objeto a través de un enlace, porque al recibir un enlace, el sistema lee el objeto completo, y si contiene detalles "restringidos", el objeto no será leído.

Por lo tanto, cuando trabaje programáticamente con objetos de bases de datos, debe tener en cuenta posibles restricciones a nivel de registro y obtener todos los datos necesarios del objeto mediante solicitud y luego colocarlos en una estructura o ejecutar parte del código en un módulo privilegiado.

Después de configurar la restricción de acceso, la visualización de la línea en la lista de derechos cambió: se volvió gris y apareció un icono.

Restricciones al configurar el acceso (RLS).

• No hay una sección de Resumen;
• No se puede acceder a las mesas de registro virtuales;
• No puede utilizar parámetros explícitamente;
• Se puede utilizar en consultas anidadas. cualquier>/span> herramientas de lenguaje de consulta excepto:
  • operador EN JERARQUÍA;
  • RESULTADOS propuestas;
  • resultados de consultas anidadas no debe contener partes de la tabla>/span>;
  • mesas virtuales, en particular Saldos y Volumen de Negocios

Práctica 2. Nomenclatura con precio actual.

Realice una restricción de acceso si necesita mostrar artículos con un precio actual superior a un valor determinado, por ejemplo, 100.

Solución:

Estamos agregando una nueva regla de restricción de acceso para el directorio "Nomenclatura" con el derecho de "lectura".
Seleccione "otros campos".
En el constructor agregamos una consulta anidada. En él, seleccione la tabla de registro de información “Precios de artículos”.
No hay una pestaña de "orden": esta es una característica del diseñador de consultas para crear una solicitud de restricción de acceso.
En la pestaña "Avanzado", configure "primer 999999999", aparece la pestaña "pedido".
Configuramos el orden por el campo "Período" en orden descendente.
Luego configuramos una conexión entre la tabla principal y la subconsulta por referencia.

Plantillas de restricción de acceso.

Práctica 3. Restricción de “contrapartes” por valor en una constante.

Configuremos una restricción de acceso para el directorio de Contrapartes según el valor almacenado en Constante.

Además, debe configurar una restricción para todos los objetos que utilizan el directorio "Contrapartes" en los detalles.

Solución

Para el directorio "Contrapartes", configuraremos una restricción para el derecho de "lectura" agregando una consulta anidada a la constante en la sección "Condiciones". No olvides que este es un grupo.

Vemos un problema, el directorio de Contrapartes está filtrado correctamente y se muestran todos los documentos con el atributo “Contraparte”, algunos con enlaces “rotos” en el atributo “Contraparte”.

Ahora necesita configurar restricciones de acceso para todos los objetos que usan el enlace a "Cuentas". Encontrémoslos utilizando el servicio "buscar enlaces a un objeto".

Copiemos y modifiquemos ligeramente el texto de la condición RLS del directorio “Contrapartes”. Esto debe hacerse tantas veces como objetos se encuentren.

O utilice un patrón de restricciones de acceso para evitar problemas de duplicación de código.

Las plantillas de restricción de acceso se configuran a nivel de rol y se pueden usar para cualquier objeto dentro del rol editado.

Puede agregar cualquier texto de restricción de acceso a la plantilla. La plantilla se llama usando el símbolo “#”. Por ejemplo, #PlantillaContraparte.

A través de # en 1C, las instrucciones se escriben en el preprocesador. En el contexto de ejecutar la configuración de restricción de acceso, la plataforma reemplaza el texto de llamada de la plantilla con el texto de la plantilla.

Agreguemos el texto después de la palabra DÓNDE a la plantilla “Plantilla de contratista”, excepto el texto sobre EtoGroup.

Parámetros en plantillas de restricción de acceso.

Sigamos resolviendo el problema 2.

El problema ahora es que la tabla principal del directorio se llama “contraparte”, en el documento “Recibo de factura”. El campo que se verifica en el directorio se llama "enlace", en el documento se llama "Contraparte".

Cambiemos el nombre de la tabla principal en el texto de la plantilla a "#CurrentTable"

"#CurrentTable" es un parámetro predefinido.

Y mediante un punto indicamos el número del parámetro de entrada - “.#Parameter(1)

“#Parámetro” también es un valor predefinido. Puede contener un número arbitrario de parámetros de entrada. Están direccionados por número de serie.

En el texto de las restricciones de acceso al directorio indicamos lo siguiente:

Para el documento lo siguiente:

“Ventas de Bienes DONDE #TemplateCounterparty (“Contraparte”)”

Al llamar a una plantilla de restricción de acceso, los parámetros se le deben pasar solo como una cadena, es decir, entre comillas.

Tabla principal - Nomenclatura

El texto de la plantilla es:

#TablaActual DONDE #TablaActual.#Parámetro(1) = #Parámetro(2)

El texto de la plantilla contiene parte del texto en el idioma de restricción de acceso a datos y puede contener parámetros que se resaltan con el símbolo "#".

El símbolo "#" puede ir seguido de:

• Una de las palabras clave:
  • Un parámetro seguido del número del parámetro en la plantilla entre paréntesis;
  • CurrentTable – indica la inserción en el texto del nombre completo de la tabla para la cual se está construyendo la restricción;
  • Nombre de la tabla actual– indica la inserción en el texto del nombre completo de la tabla (como un valor de cadena, entre comillas) a la que se aplica la instrucción, en la versión actual del lenguaje integrado;
  • NombreAccesoActualDerecho– contiene el nombre del derecho para el cual se ejecuta la restricción actual: LEER, AGREGAR, INSERTAR, CAMBIAR, ACTUALIZAR, ELIMINAR;
• nombre del parámetro de plantilla: significa la inserción de la restricción del parámetro de plantilla correspondiente en el texto;
• símbolo “#” – indica la inserción de un carácter “#” en el texto.

Una expresión de restricción de acceso puede contener:

• Plantilla de restricción de acceso, que se especifica en el formato #TemplateName("Valor de parámetro de plantilla 1", "Valor de parámetro de plantilla 2",...). Cada parámetro de plantilla está entre comillas dobles. Si necesita especificar un carácter de comilla doble en el texto del parámetro, debe utilizar dos comillas dobles.
• Función StrContains(DóndeMiramos, QuéMiramos). La función está diseñada para buscar una aparición de la cadena WhatWeLook en la cadena WhereWeLook. Devuelve True si se encuentra la ocurrencia y False en caso contrario.
• El operador + es para la concatenación de cadenas.

Para facilitar la edición del texto de la plantilla, en la pestaña Plantillas de restricción en el formulario de rol, haga clic en el botón Establecer texto de plantilla. En el cuadro de diálogo que se abre, ingrese el texto de la plantilla y haga clic en Aceptar.

No se pueden instalar usando Establecer parámetro() o algo parecido.

Los parámetros en este caso son:

• Opciones de sesión
• Opciones funcionales

La lectura de los parámetros de sesión en una solicitud de restricción de acceso se produce en modo privilegiado, es decir, sin controlar los derechos para operar con ellos.

Práctica 4. Acceso a “tus” contrapartes

Es necesario configurar la restricción del acceso del usuario actual a "sus" contrapartes.

Hay un directorio “Usuarios”, un directorio “Contrapartes”, documentos con el detalle “Contraparte”.

El usuario actual debería ver los datos sólo de aquellas contrapartes para las que se ha establecido una conexión con él.

También es necesario configurar la comunicación.

Posibles opciones:

Establecer conexiones entre usuario y contraparte

• Detalles en el directorio de contrapartes
• registro de informacion

Posibles soluciones al problema:

• Almacenar un usuario en una constante es una mala opción; la constante está disponible para todos los usuarios.
• Almacenar una matriz fija de las contrapartes del usuario actual en los parámetros de la sesión no es una muy buena opción; puede haber muchas contrapartes;
• Almacenar en los parámetros de sesión del usuario actual y luego solicitar una lista de "sus" contrapartes es una opción aceptable.
• Otras opciones.

Solución.

Creemos un nuevo parámetro de sesión "CurrentUser" y completémoslo en el módulo de sesión.

Creemos un registro de información “Cumplimiento de encargados y contratistas”

Creemos un nuevo rol y en él una nueva restricción de acceso al documento “Factura”.

En el texto de la solicitud, conectaremos la tabla principal con el registro de información para Cuenta = Cuenta y Administrador = & Usuario actual. Tipo de conexión Interna.

Si es posible, es mejor evitar consultas anidadas en los textos de restricción de acceso, ya que se ejecutarán cada vez que se lean datos de este objeto desde la base de datos.

Comprobación: las restricciones funcionan

*Característica: Si cambia la lista de contrapartes de usuarios en el registro, las restricciones de acceso entrarán en vigor inmediatamente sin reiniciar la sesión del usuario.

Práctica 5. Fecha de prohibición de cambios.

Es necesario implementar una restricción a la edición de datos antes de la fecha establecida para la prohibición de cambios.
Debe limitarlo para los usuarios.

Creemos un registro de información “Fechas de Prohibición de Cambios” con la dimensión Usuario, recurso Fecha de Prohibición.

Construyamos la lógica de la solución de esta manera:

• Si no se especifica un usuario, la prohibición se aplica a todos los usuarios.
• si hay una restricción para todos los usuarios y una restricción para un usuario específico, entonces la restricción se aplica a un usuario específico y a otros de acuerdo con el principio general.

Obviamente, dicha restricción se puede configurar para objetos de base de datos que tienen alguna posición en el eje de tiempo. podría ser

• Documentos
• Registros de información periódica.

Creemos un nuevo rol “Restricciones Por Fecha de Prohibición de Cambios”.

En él, para el documento “Factura” por el derecho “cambiar” agregaremos una nueva restricción de acceso.

Especificamos la configuración para todos los campos.

El texto de la restricción es:

ReciboInvoice FROM Document.ReceiptInvoice AS ReciboInvoice

Cambiar fechas de prohibición como fecha de prohibición.
DE

UNIÓN INTERNA (SELECCIONAR
MAX(Cambiar fechas prohibidas.Usuario) COMO usuario
DE
Registro de Información Fechas de Prohibición de Cambios AS Fechas de Prohibición de Cambios.
DÓNDE
(Cambiar fechas prohibidas. Usuario = & Usuario actual
O Fechas ProhibitedChanges.Usuario = VALOR(Directorio.usuarios.EmptyLink))) AS VZ_User
BY Fecha de Prohibición de Cambios.Usuario = VZ_User.User) AS NestedQuery
Factura de recibo de software. Fecha > Consulta anidada. Fecha de prohibición

Comprobemos: la restricción funciona.

Uso de instrucciones del preprocesador

#Si Condición1 #Entonces

Solicitar fragmento 1

#ElseIf Condición2 #Entonces

Solicitar fragmento 2

#De lo contrario

Solicitar fragmento 3

#FinSi

En condiciones, puede utilizar operaciones lógicas (y. o, no, etc.) y acceder a los parámetros de la sesión.

Este enfoque en el contexto de la construcción de restricciones de acceso es conveniente porque, dependiendo de las condiciones, se compilará un texto de solicitud más corto. Una consulta más sencilla carga menos el sistema.

La desventaja es que el constructor de consultas no funcionará con dicho texto.

*Peculiaridad:

A diferencia de las instrucciones para el preprocesador del lenguaje integrado en los textos de restricción de acceso, antes del operador Entonces es necesario poner un hash - #Entonces

Práctica 6. Cambie “Usar RLS”

Complementemos nuestro sistema de restricciones con un interruptor que activa/desactiva el uso de restricciones a nivel de registro.

Para hacer esto, agregue una constante y un parámetro de sesión llamado "UseRLS".

Escribamos en el módulo de sesión para establecer el valor del parámetro de sesión a partir del valor de la constante.

Agreguemos el siguiente código a todos los textos de restricción de acceso:

“#Si &UseRLS #Entonces….. #FinalizarSi”

Lo comprobamos: todo funciona.

Sin embargo, ahora, después de activar la bandera "usar radar", los cambios no entrarán en vigor de inmediato. ¿Por qué?

Porque el parámetro de sesión se establece cuando se inicia la sesión.

Es posible configurar el valor del parámetro de sesión para que se restablezca cuando se escribe un nuevo valor constante, pero esto solo funcionará para la sesión de usuario actual. A otros usuarios se les debería solicitar que reinicien el sistema.

Fin de la primera parte.

La plataforma 1C:Enterprise 8 tiene un mecanismo incorporado para restringir el acceso a los datos a nivel de registro. Puedes leer información general al respecto aquí. En resumen, RLS le permitirá restringir el acceso a los datos según ciertas condiciones en los valores de los campos. Por ejemplo, puede restringir el acceso de los usuarios a los documentos según el valor del atributo "Organización". Algunos usuarios trabajarán con documentos para la organización “Empresa administradora” y otros con la organización “Planta lechera”. Como ejemplo.

Preparación

Implementaremos el ejemplo en la configuración de demostración de SCP 1.3. Creemos un usuario "Tienda" y agréguemosle el rol del mismo nombre "Tienda".

Ahora procedamos directamente a configurar los derechos de acceso a nivel de registro. Pasemos a la interfaz "Administración de usuarios". En el menú principal, seleccione "Acceso a nivel de registro -> Opciones". Aquí, marque la casilla "Restringir el acceso a nivel de registro por tipo de objeto" y seleccione "Organizaciones" en la lista de objetos.

Así, habilitamos el uso de RLS. Ahora necesitas configurarlo.

El control de acceso a nivel de registro no se configura por separado para cada usuario o perfil de permiso. RLS está configurado para grupos de usuarios. Agreguemos un nuevo grupo de usuarios, llamémoslo "Tiendas".

La composición del grupo en el lado derecho del formulario muestra una lista de usuarios que pertenecen a este grupo. Agreguemos el usuario que creamos anteriormente a la lista. A la izquierda hay una tabla de restricciones de acceso. Al configurar RLS, elegimos que el acceso esté limitado solo por la organización, por lo que solo vemos un tipo de objeto de acceso. Haga clic en el botón "Configuración de acceso". Se abrirá el proceso de configuración de derechos de acceso para el grupo actual.

Agreguemos la organización "IPE "Entrepreneur" a la lista de objetos de acceso para el grupo. El tipo de herencia de derechos se mantendrá sin cambios. Estableceremos el derecho al objeto de acceso para lectura y escritura. Haga clic en "Aceptar", la configuración está lista. Acabamos de configurar RLS a nivel de organización.

Lo que ve el usuario

Iniciemos el programa con el usuario creado anteriormente y abramos el directorio "Organizaciones". Así es como se verá la lista para nuestro usuario y para un usuario con todos los derechos:

Como podemos ver, el usuario almacenista ve solo una organización a la que le hemos otorgado acceso de lectura. Lo mismo se aplica a los documentos, por ejemplo, la recepción de bienes y servicios.

Por lo tanto, el usuario no sólo no verá las organizaciones para las que no tiene acceso establecido, sino que tampoco podrá leer/escribir documentos y otros objetos en la base de información para los cuales los derechos están establecidos en el rol de "Organización". atributo.

Analizamos el ejemplo más simple de configuración de RLS. En el próximo artículo hablaremos sobre la implementación del mecanismo RLS en la configuración "Manufacturing Enterprise Management" versión 1.3.