PDA

Ver la Versión Completa : Evitar que un usuario se conecte dos veces


Angel.Matilla
26-03-2021, 19:40:01
En un BB.DD. con FB 2.5.6 quiero implementar un sistema para qu el mismo usuario no pueda conectarse desde dos puestos diferentes de forma simultánea. He estado dando vueltas por ahí y en el blog Firebird SQL encontré este código (https://firebird21.wordpress.com/2014/06/05/evitando-que-un-usuario-se-conecte-mas-de-una-vez-metodo-mejorado/) que usa una tabla y dos triggers:
CREATE TABLE CONEXION (
CON_IDENTI INTEGER NOT NULL,
CON_IDECON INTEGER NOT NULL,
CON_NOMBRE VARCHAR(15) CHARACTER SET ISO8859_1 NOT NULL COLLATE ES_ES_CI_AI,
CON_TIMEST TIMESTAMP);

ALTER TABLE CONEXION ADD CONSTRAINT PK_CONEXION PRIMARY KEY (CON_IDENTI);

ALTER TABLE CONEXION ADD CONSTRAINT UQ_CONEXION UNIQUE (CON_NOMBRE);
Al conectarse a la BB.DD.:
CREATE TRIGGER CONECTADO
ACTIVE ON
CONNECT
POSITION 2
AS
BEGIN

-- Primero, se borran las filas de los usuarios que no estan conectados
-- pero aparecen como conectados
DELETE FROM Conexion
WHERE CON_IDECON NOT IN (SELECT MON$ATTACHMENT_ID FROM MON$ATTACHMENTS);

-- Segundo, se trata de insertar una fila a la tabla CONEXION.
-- Como la tabla CONEXION tiene una restriccion UNIQUE KEY, un usuario
-- no se podra conectar mas de una vez al mismo tiempo
INSERT INTO Conexion (CON_IDENTI, CON_IDECON, CON_NOMBRE, CON_TIMEST)
VALUES (0, CURRENT_CONNECTION, CURRENT_USER, CURRENT_TIMESTAMP);
END
Al desconectarse
CREATE TRIGGER DESCONECTADO
ACTIVE ON
DISCONNECT
POSITION 1
AS
BEGIN
DELETE FROM Conexion WHERE Con_Nombre = CURRENT_USER;
END
Si entro una primera vez con un usuario, al tabla CONEXION queda así:
https://i.ibb.co/LRKc9Q9/Conexion1.jpg

Si ahora accedo con un segundo usuario, sin cerrar la sesión anterior, la tabla queda así:
https://i.ibb.co/DDGJ4Tn/Conexion2.jpg

Sin embargo, si sin cerrar ninguna de las dos sesiones hago un SELECT sobre la tabla MON$ATTACHMENTS se muestra esto:
https://i.ibb.co/8Kz6qpP/Conexion3.jpg
Como se puede ver ambos usaurios están activos pero en la tabla CONEXION sólo se muestra el que ha entrado último. ¿Alguien me puede explicar la razón? No acabo de entender que puede estar pasando.

Casimiro Notevi
26-03-2021, 21:38:01
No recuerdo bien cómo iba esa tabla, pero parece que están conectados 3 ususarios: sysdba, juani y angel.
Hay otro sysdba que no está conectado (o está inactivo), mon$state=0 y los demás están en con el valor 1.

mamcx
26-03-2021, 23:39:25
Que alocada razón hay para imponer tal restricción?

Angel.Matilla
27-03-2021, 09:43:07
No recuerdo bien cómo iba esa tabla, pero parece que están conectados 3 ususarios: sysdba, juani y angel.
Hay otro sysdba que no está conectado (o está inactivo), mon$state=0 y los demás están en con el valor 1.
Uno de los sydba aparece porque las capturas de pantalla están hechas con SQLManager; imagino que será el que aparece como activo. Lo que sí me has dado una pista interesante que tengo que probar y es comprobar el estado del usuario.
Que alocada razón hay para imponer tal restricción?
¿Y que sentido tiene que el mismo usuario pueda abrir sesión en dos puestos diferentes? Lo entiendo como medida de seguridad.

Angel.Matilla
27-03-2021, 10:01:31
Lo que sí me has dado una pista interesante que tengo que probar y es comprobar el estado del usuario.
¡Era demasiado fácil! He modificado el trigger así:
CREATE TRIGGER CONECTADO
ACTIVE ON
CONNECT
POSITION 2
AS
BEGIN

-- Primero, se borran las filas de los usuarios que no estan conectados
-- pero aparecen como conectados
DELETE FROM Conexion
WHERE CON_IDECON NOT IN (SELECT MON$ATTACHMENT_ID FROM MON$ATTACHMENTS WHERE MON$STATE = 1);

-- Segundo, se trata de insertar una fila a la tabla CONEXION.
-- Como la tabla CONEXION tiene una restriccion UNIQUE KEY, un usuario
-- no se podra conectar mas de una vez al mismo tiempo
INSERT INTO Conexion (CON_IDENTI, CON_IDECON, CON_NOMBRE, CON_TIMEST)
VALUES (0, CURRENT_CONNECTION, CURRENT_USER, CURRENT_TIMESTAMP);
END
En teoría así sólo borraría aquellas filas de la tabla Conexion que en MON$ATTACHMENTS estuvieran con estado 0 ya que eso significaría que el usuario está inactivo. Pero no, sigue borrando la fila del usuario ANGEL a pesar de que no debería. Sin embargo, si ejecuto ese trozo del trigger (DELETE) desde SQLManager no borra ninguna entrada. CAda vez lo entiendo menos.

Angel.Matilla
27-03-2021, 10:07:30
No recuerdo bien cómo iba esa tabla, pero parece que están conectados 3 ususarios: sysdba, juani y angel.
Hay otro sysdba que no está conectado (o está inactivo), mon$state=0 y los demás están en con el valor 1.
He estado hacienod algunas pruebas con SQLManager y he llegado a la conclusión que aparece un usuario sysdba por cada pestaña que se tiene abierta y otro más (que ha de ser el mon$state=0) que corresponde al propio SQLManager.

Casimiro Notevi
27-03-2021, 19:06:21
Mira si te sirve esto (https://firebird21.wordpress.com/2013/12/01/limitando-la-cantidad-de-usuarios-conectados/).

Angel.Matilla
29-03-2021, 10:08:06
Gracias por la sugerencia. El problema que veo yo, y no me explico, es por qué funciona distinto ese DELETE FROM si está dentro o fuera del trigger ya que como he comentado: si se ejecuta dentro del trigger borra todas las filas que haya independientemente del estado; si se ejecuta fuera deja las que están activas. Veo que la solución pasa por ejecutar el DELETE antes de que se lance el trigger.