Alcanzar¶

El alcance es App Builder despliegue de seguridad a nivel de fila (RLS) de Reach. Reach permite a los desarrolladores de aplicaciones restringir qué filas están disponibles para cada usuario.

Muchos sistemas de administración de bases de datos relacionales (RDBMS) ofrecen compatibilidad nativa con RLS. Reach no es una abstracción para estas ofertas nativas. En cambio, Reach se implementa mediante el App Builder motor de negocios. Como resultado, Reach es independiente de la base de datos.

Casos de Uso¶

Los casos de uso comunes de Reach incluyen:

• Asignación: los vendedores solo pueden administrar los clientes potenciales que se les asignan directamente.
• Unidades organizativas: Reach puede restringir el acceso de los empleados a los datos por región geográfica o división.
• Multiusuario: si una aplicación admite varios clientes, Reach puede limitar el acceso del cliente a su segmento de datos.

Conceptos¶

Reach se compone de los siguientes conceptos básicos:

• Regla de Reach
• Token de Reach
• Registro de Reach

Regla de Alcance¶

Una regla de alcance es un tipo de regla de negocio como una regla predeterminada o de validación. Al igual que con todas las reglas de negocio, las reglas de alcance son fundamentalmente consultas mvSQL.

La regla de alcance determina a qué segmentos de los datos puede acceder un usuario. En muchos casos, una regla de alcance utilizará la who() o session() Funciones mvSQL para correlacionar el usuario actual con los datos a los que puede acceder.

Token de Alcance¶

Cada regla de alcance selecciona una y solo una columna designada como token de alcance. Esta columna se identifica por el tipo de uso de columna "Token de alcance".

El token de alcance identifica segmentos de los datos a los que puede acceder el usuario. Una regla de alcance puede devolver varias filas, cada una de las cuales identifica un segmento diferente. Si la regla no devuelve ninguna fila, el usuario no tendrá acceso a ningún dato.

Por razones de rendimiento, el token de alcance generalmente identifica un segmento de filas, no filas individuales. Por ejemplo, un token de alcance puede identificar una región geográfica. Un gerente de ventas solo podrá generar informes para los clientes dentro de su región.

Por lo general, un token de alcance no identificaría a clientes individuales. Sin embargo, existen excepciones. Al crear un sistema multi-inquilino, el token de alcance puede identificar la fila de clientes del usuario. En este escenario, el cliente es el segmento.

Registro de Alcance¶

Los desarrolladores deben registrar explícitamente una regla de alcance en un objeto de datos. Un objeto de datos puede tener varios registros. En ese caso, la intersección de esas reglas de alcance determina a qué filas puede acceder el usuario.

Un registro de alcance incluye lo siguiente:

• Regla de alcance: la regla que restringe qué segmentos del objeto de datos son accesibles para el usuario.
• Columna de enlace: la columna del objeto de datos enlazada por el token de alcance.
• Rol: el rol para el que se aplica la regla de alcance. Si no está asociada con un rol, la regla se aplica a todos los usuarios.
• Activo: habilita o deshabilita la regla de alcance para fines de desarrollo y prueba.
• Índice: orden en el que se aplican las reglas de alcance.

Despliegue¶

Todo App Builder las reglas respaldan un conjunto de eventos intrínsecos. Filter el evento es responsable de recuperar filas. El alcance lo aplica el Filter evento.

En consecuencia, Reach es compatible con los siguientes escenarios:

• Paneles: incluye paneles de varias filas y de una sola fila, gráficos y calendarios, etc.
• Controles: incluye controles de lista y de opción.
• CRUD: incluye solo reglas CRUD empresariales, no reglas CRUD directas a la base de datos.

Ejemplo¶

Dado el siguiente esquema de tabla:

En este modelo:

• Tanto los empleados como los clientes pertenecen a una región.
• Cada empleado está asociado a una an App Builder usuario.

La siguiente regla de alcance restringe a los usuarios de modo que solo puedan acceder a los clientes de su propia región:

SELECT RegionId
FROM Employee
WHERE UserId = who('userid')

Suponiendo que la regla de alcance apunta a la Customer tabla, se puede registrar en la Customer (Source)objeto de datos. En ese momento, Reach se aplicará a todos los paneles vinculados al Customer (Source) objeto de datos.

En muchos casos, Reach solo se debe aplicar a algunos usuarios. Esto se puede lograr con la seguridad basada en roles (RBS). Por ejemplo, supongamos que la fuente de datos define los siguientes roles:

• Administrador - Puede acceder a todos los clientes.
• Ventas - Solo pueden acceder clientes de su propia región.

Al registrar la regla Reach, asóciela con el rol_Sales_. Esto garantizará que Reach solo se aplique a los usuarios con el rol_Sales_: los usuarios con el rol Administrator tendrán acceso a todos los clientes.

Limitaciones¶

• Reach solo es compatible actualmente con fuentes de datos RDBMS.
• Reach no es compatible actualmente con operaciones multiplataforma: la regla de Reach y el objeto de datos deben pertenecer a la misma fuente de datos de origen.
• Reach no es compatible con operaciones CRUD directas de base de datos. Reach se aplica mediante el motor de negocios: las operaciones directas de base de datos pasan por alto el motor de negocios.
• Una regla de Reach solo puede tener una columna de token de Reach. En consecuencia, los objetos de datos están vinculados a las reglas de Reach mediante una sola columna. Esto difiere de otros tipos de reglas que permiten a los desarrolladores vincular objetos de datos a reglas mediante varias columnas.
• Reach no es compatible actualmente junto con la regla de Reach. App Builder conector.
• Copiar un objeto de datos no copia los registros de alcance. Esto es coherente con otros tipos de reglas: los valores predeterminados, las validaciones y las acciones tampoco se copian.