Las consultas de datos de inquilinos (tenants) no devuelven registros después de habilitar Row-Level Security en tablas nuevas

Question

Las consultas de datos de inquilinos (tenants) no devuelven registros después de habilitar Row-Level Security en tablas nuevas

Santillán Nerea 20

Acabamos de crear unas tablas nuevas, aunque todo funcionaba bien con la configuración anterior. Ahora nuestras consultas de datos de inquilinos (tenants) no devuelven registros correctamente después de habilitar las políticas de seguridad a nivel de fila (Row-Level Security) en estas tablas nuevas. La mayoría de las veces simplemente no devuelven nada en absoluto, incluso cuando los datos están ahí y funcionan bien sin las políticas activas. Actúa como si hubiera un problema con el contexto de la conexión, como si la variable del inquilino necesitara configurarse pero no hubiera ningún valor asociado. ¿Cómo podemos inspeccionar las variables de sesión activas de la base de datos?

0 comentarios

1 respuesta

Su respuesta

Answer 1

Hola Santillán Nerea,

En Microsoft SQL Server o Azure SQL Database, las variables de sesión se establecen mediante sys.sp_set_session_context y deben inspeccionarse individualmente ejecutando SELECT SESSION_CONTEXT(N'YourTenantKey'. Para verificar el nombre exacto de clave y conversión de tipo de datos, ejecuta SELECT sp.name AS PolicyName, OBJECT_NAME(pr.target_object_id) AS TableName, m.definition AS PredicateLogic FROM sys.security_predicates pr INNER JOIN sys.security_policies sp ON pr.object_id = sp.object_id INNER JOIN sys.sql_modules m ON pr.predicate_id = m.object_id;. Al comparar PredicateLogic entre la tabla antigua y la nueva, verifica la mayúscula exacta de la cadena de claves, porque SESSION_CONTEXT las búsquedas de clave en SQL Server son estrictamente sensibles a mayúsculas y minúsculas independientemente de la clasificación de la base de datos; si tu conexión se inicializa N'TenantId' pero el predicado de la nueva tabla se comprueba N'tenantid', devolverá NULL.

En PostgreSQL o Azure Database for PostgreSQL, las variables de sesión RLS personalizadas no aparecen en pg_settings, por lo que primero deberías inspeccionar la expresión de política en las nuevas tablas ejecutando SELECT tablename, policyname, qual, with_check FROM pg_policies WHERE tablename = 'your_new_table';. Después de identificar el nombre de la variable dentro de la qual columna, inspecciona su valor en vivo en tu sesión SELECT current_setting('your.variable_name', true); ejecutando o SHOW your.variable_name;. Si el nombre de la variable en las nuevas tablas es correcto pero las consultas siguen devolviendo resultados vacíos la mayoría de las veces, el culpable es el agrupamiento de conexiones o el alcance de transacciones: el código que consulta tus nuevas tablas probablemente esté tomando prestadas conexiones agrupadas sin inicializar primero la variable de sesión—solo devolviendo datos cuando reutiliza aleatoriamente una conexión que antes estaba poblada por una consulta antigua—o, en PostgreSQL, está llamando SET LOCAL o set_config(..., true) fuera de un bloque de transacción explícito BEGIN ... COMMIT , haciendo que la variable se reinicie inmediatamente antes de que se ejecute la SELECT consulta.

Espero que esta respuesta te haya aportado información útil. Si es así, por favor pulsa "aceptar respuesta". Si tienes alguna pregunta, no dudes en dejar un comentario.

VPHAN