Usuarios y seguridad en Firebird 3 (3)

1 comentario

Este tema de la administración de los usuarios es interesante y es importante, así que continuemos.

Como ya habíamos visto en el anterior artículo de esta serie, en nuestro archivo de texto plano llamado DATABASES.CONF tenemos lo siguiente:

Listado 1. El contenido del archivo DATABASES.CONF

MARCELA = D:\SISTEMAS\CONTABILIDAD\DATABASES\MARCELA.FDB
 
SILVIA = D:\SISTEMAS\CONTABILIDAD\DATABASES\SILVIA.FDB
{
  SecurityDatabase = E:\SEGURIDAD\USUARIOS_OK.FDB
}
 
SUSANA = D:\SISTEMAS\CONTABILIDAD\DATABASES\SUSANA.FDB
{
  SecurityDatabase = SUSANA
}
 
VERONICA = D:\SISTEMAS\CONTABILIDAD\DATABASES\VERONICA.FDB
{
  SecurityDatabase = VERONICA
}
 
security.db = E:\SEGURIDAD\PERMISOS.FDB

Por lo visto ahí podemos deducir que hay varias «bases de datos de seguridad» cuyos nombres son: usuarios_ok.fdb, susana.fdb, veronica.fdb, permisos.fdb. Entonces:

  1. ¿Cómo creamos una nueva «Base de Datos de seguridad»?
  2. ¿Cómo le agregamos usuarios?
  3. ¿Cómo conseguimos que la «Base de Datos de seguridad» sea la misma que la Base de Datos normal?

Crear una «Base de Datos de Seguridad»

Esto es muy simple. Y hay 2 formas de hacerlo.

  1. Copiamos el archivo security3.fdb.empty que se encuentra en la misma carpeta en donde se instaló al Firebird 3 y lo pegamos en cualquier otra carpeta y le cambiamos el nombre.

Por ejemplo: copiamos a security3.fdb.empty en la carpeta E:\SEGURIDAD\ y lo renombramos como usuarios_ok.fdb

2. Creamos una Base de Datos con el programa ISQL.EXE, algo como:

Captura 1. Creamos una Base de Datos vacía

Fíjate que aunque no exista aún el usuario SYSDBA debes escribir ese nombre.

Agregar usuarios a una «Base de Datos de seguridad»

Aquí debes prestar mucha atención porque esto no es intuitivo, no es lo que uno esperaría.

Y es que para agregarle usuarios no debes estar conectado a la «Base de Datos de seguridad» sino que debes estar conectado a una Base de Datos normal, cuyo parámetro SecurityDatabase apunte a la «Base de Datos de seguridad».

Por ejemplo: la «Base de Datos de seguridad» de silvia.fdb se especificó que sea: E:\SEGURIDAD\USUARIOS_OK.FDB, entonces para agregarle usuarios a usuarios_ok.fdb debes conectarte a silvia.fdb, y no a usuarios_ok.fdb como podrías suponer.

¿Verdad que es raro? pero bueno, ¡¡¡así funciona!!!

Otra cosa rara es que debes conectarte como SYSDBA aún cuando no exista un usuario SYSDBA.

El programa que puedes utilizar para realizar esta tarea se llama ISQL.EXE y viene incluido con el Firebird.

Captura 2. Usando al programa ISQL para conectarse a una Base de Datos

El usuario SYSDBA aún no existe, pero debe ser especificado. Y no necesitas escribir un password (ya que si lo escribes, será ignorado, no se usará).

Captura 3. Creando al usuario SYSDBA

NOTA: No es obligatorio que crees a un usuario con el nombre SYSDBA. Mucha gente se acostumbró a tener un super-usuario llamado SYSDBA pero no es obligatorio en Firebird 3 tenerlo.

Con el comando CREATE USER podemos crear a todos los usuarios que deseemos crear.

Captura 4. Creando al usuario ALEJANDRA

Hasta Firebird 2.5.9 un password podía tener un máximo de 8 caracteres. Desde Firebird 3 puede tener un máximo de 255 caracteres pero se provee seguridad por los primeros 20 caracteres (eso significa que si escribes un password de más de 20 caracteres existe una posibilidad remota, pero existe, de que su hash sea igual a un hash de hasta 20 caracteres).

Para que el usuario sea creado debes escribir el comando COMMIT.

Hacer que una Base de Datos normal sea su propia «Base de Datos de seguridad»

Esto es muy sencillo. Lo que debes hacer es que en el archivo DATABASES.CONF el parámetro SecurityDatabase tenga el mismo alias que la Base de Datos normal. Luego, reiniciar el Servidor del Firebird, luego conectarte a tu Base de Datos normal, y a partir de ese momento el comando CREATE USER creará a los usuarios dentro de la Base de Datos normal.

Por ejemplo: en el Listado 1. hay una Base de Datos cuyo alias es VERONICA. Si te conectas a VERONICA y escribes el comando CREATE USER ese usuario se creará dentro de VERONICA. ¿Por qué? porque el alias es igual al valor del parámetro SecurityDatabase.

Conectándose a una «Base de Datos de seguridad»

En Firebird 3 puedes conectarte a una «Base de Datos de seguridad» exactamente de la misma manera en que puedes conectarte a una Base de Datos normal.

Captura 5. La conexión a una «Base de Datos de seguridad» está permitida

Para ver las tablas puedes escribir el comando:

SHOW TABLES;

Y para ver el contenido escribes un SELECT, como siempre, algo como:

SELECT * FROM PLG$SRP;

En la tabla PLG$SRP se guardan los datos de los usuarios que tú has creado.

Agregando usuarios a la «Base de Datos de seguridad» por defecto.

La «Base de Datos de seguridad» por defecto es security3.fdb y se encuentra en la carpeta donde se instaló el Firebird 3., salvo que hayas cambiado el valor del parámetro SecurityDatabase del archivo FIREBIRD.CONF.

Igual que antes, para agregarle usuarios debes conectarte no a security3.fdb (o su reemplazante) sino a una Base de Datos normal. Por ejemplo, como alicia.fdb no tiene un alias en el archivo DATABASES.CONF entonces si te conectas a alicia.fdb y escribes el comando CREATE USER ese usuario será agregado a la «Base de Datos de seguridad» por defecto (que en nuestro ejemplo será permisos.fdb).

En este artículo, la «Base de Datos de seguridad» por defecto es E:\SEGURIDAD\PERMISOS.FDB porque es la especificada en el alias security.db del archivo DATABASES.CONF.

Agregando usuarios después de instalar al Firebird 3

Si inmediatamente después de haber instalado el Servidor del Firebird 3 ya quieres agregar usuarios, ¿cómo lo consigues?

Como recordarás, para agregar usuarios a una «Base de Datos de seguridad» debes estar previamente conectado a una Base de Datos normal.

Para que puedas hacerlo desde el primer instante es que al instalar al Firebird 3 se copia una Base de Datos de ejemplo llamada employee.fdb

Si no modificaste el parámetro SecurityDatabase del archivo FIREBIRD.CONF entonces la «Base de Datos de seguridad» será security3.fdb

Captura 6. Creando usuarios inmediatamente después de instalar al Servidor del Firebird

En este caso, la Base de Datos normal es employee.fdb, que trae como ejemplo el Firebird. Y la «Base de Datos de seguridad» por defecto es security3.fdb

Entonces, si no cambiaste a la «Base de Datos de seguridad» en el archivo FIREBIRD.CONF mediante el parámetro SecurityDatabase, el usuario WALTER y el usuario OJEDA se guardarán en security3.fdb

Artículos relacionados:

Usuarios y seguridad en Firebird 3 (1)

Usuarios y seguridad en Firebird 3 (2)

Usuarios y seguridad en Firebird 3 (4)

Usuarios y seguridad en Firebird 3 (5)

Usuarios y seguridad en Firebird 3 (6)

El índice del blog Firebird21

Firebird 3: usando bases de datos anteriores

8 comentarios

Ok, ya hemos instalado a Firebird 3, ahora queremos empezar a utilizarlo. ¿Cómo lo hacemos?

Lo más probable es que tengamos bases de datos creadas con versiones anteriores de Firebird. Entonces hay que convertir esas bases de datos al formato que usa Firebird 3.

El Firebird utiliza un número interno llamado ODS (On Disk Structure) para saber con cual versión de Firebird fue creada una Base de Datos. Cada versión del Firebird tiene un número único de ODS. Esos números son:

FIREBIRD3_15

Captura 1. Si haces clic en la imagen la verás más grande

Si no coincide la ODS de una Base de Datos con la versión del Servidor del Firebird entonces no podremos conectarnos a esa Base de Datos.

¿Cómo cambiamos la ODS de una Base de Datos?

Mediante un ciclo backup/restore. Hacemos el backup con la versión actual y el restore con la nueva versión.

IMPORTANTE: Esto solamente funciona en una dirección: de una ODS menor a una ODS mayor.

Ejemplo: Usar una Base de Datos creada con Firebird 2.5 en Firebird 3

firebird3_16

Captura 2. Si haces clic en la imagen la verás más grande

Como podemos ver en la Captura 2. la conexión falló porque la ODS de la Base de Datos es 11.2 y la ODS que reconoce el Servidor del Firebird es 12.0

Entonces lo que debemos hacer es convertir la ODS de esa Base de Datos a 12.0, para que pueda ser reconocida. Para ello necesitaremos realizar un ciclo backup/restore.

FIREBIRD3_17

Captura 3. Si haces clic en la imagen la verás más grande

En la Captura 3. hicimos el backup con la versión 2.5 del Firebird ¿cómo sabemos eso? Por dos pistas: a) la carpeta donde se encuentra el programa GBAK.EXE y b) el puerto que usamos para conectarnos a la Base de Datos. En nuestros ejemplos usamos el puerto 3050 para Firebird 2.5 y el puerto 3053 para Firebird 3.

Ahora que ya tenemos el backup realizado el siguiente paso es restaurarlo. Para ello, nos ubicamos en la carpeta donde instalamos al Firebird 3 y escribimos:

FIREBIRD3_18

Captura 4. Si haces clic en la imagen la verás más grande

Cuando la restauración finalice tendremos una nueva Base de Datos, de nombre PRUEBA1-3.FDB y cuya ODS será 12.0 y por lo tanto nos podremos conectar a ella usando Firebird 3.

FIREBIRD3_19

Captura 5. Si haces clic en la imagen la verás más grande

Como podemos ver en la Captura 5. no fue necesario especificar el puerto 3053 ¿por qué no? porque para la conexión usamos el programa ISQL.EXE que se instala junto con el Firebird 3. Sin embargo, en otros casos sí necesitaremos especificar dicho puerto:

FIREBIRD3_20

Captura 6. Si haces clic en la imagen la verás más grande

En el string de conexión que vemos en la Captura 6. indicamos la dirección IP de la computadora donde se encuentra la Base de Datos y también el puerto de esa computadora que usa el Servidor del Firebird 3.

Como siempre, hay que indicar además el path completo a la Base de Datos (ese path es desde el punto de vista del Servidor), el nombre de un usuario, y la contraseña de ese usuario.

Conclusión:

Para que en Firebird 3 podamos usar una Base de Datos creada con una versión anterior del Firebird debemos hacer un ciclo backup/restore. El backup lo hacemos con la versión anterior del Firebird y el restore lo hacemos con Firebird 3.

Para conectarnos a la Base de Datos restaurada a veces será necesario especificar el puerto que utiliza el Firebird 3.

Artículos relacionados:

Instalando Firebird 3 (1)

Instalando Firebird 3 (2)

El índice del blog Firebird21

El foro del blog Firebird21

¿Es seguro usar Servidor y embedded al mismo tiempo?

Deja un comentario

Sí, … pero con algunas condiciones.

En ocasiones podrías querer conectarte usando Servidor (es decir: Classic, SuperClassic, o SuperServer) a una Base de Datos y en ocasiones podrías querer conectarte usando embedded. Entonces … ¿puedes hacer algo así?

Sí, pero no puedes realizar la conexión al mismo tiempo.

Veamos:

  1. Conectarse a la Base de Datos A con Servidor y a la Base de Datos A con embedded. NO PERMITIDO
  2. Conectarse a la Base de Datos A con embedded y a la Base de Datos A con Servidor. NO PERMITIDO
  3. Conectarse a la Base de Datos A con Servidor y a la Base de Datos B con embedded. PERMITIDO
  4. Conectarse a la Base de Datos A con embedded y a la Base de Datos A con embedded. NO PERMITIDO

La diferencia entre el caso 1. y el caso 2. está en quien se conectó primero a la Base de Datos A, pero sin importar quien lo haya hecho, la segunda conexión no es permitida.

Como habrás notado al mirar los casos anteriores, si te conectas por embedded, lo haces de forma exclusiva. Ninguna otra conexión a esa misma Base de Datos es permitida.

Resumiendo:

Se puede conectar usando Servidor y usando embedded en la misma computadora, pero la condición es que se haga a bases de datos distintas.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Evitando que un usuario se conecte más de una vez a la Base de Datos

17 comentarios

A veces quieres que un usuario no pueda conectarse desde más de una computadora al mismo tiempo, o desde la misma computadora más de una vez. Eso es especialmente importante en las aplicaciones de seguridad o donde se maneja dinero. Entonces, ¿cómo evitamos que lo haga?

En nuestra ayuda vienen los triggers de las bases de datos. Estos se disparan cuando alguien se conecta o se desconecta de la Base de Datos. Lo que podemos hacer es crear una tabla, la llamamos por ejemplo CONECTADOS y cada vez que alguien se conecta insertamos una fila a esta tabla, y cada vez que se desconecta borramos la fila que le corresponde.

CONECTADOS1

Captura 1. Si haces clic en la imagen la verás más grande

La columna CON_NOMBRE se encuentra en una restricción Unique Key, como podemos ver en su DDL:

ALTER TABLE CONECTADOS ADD CONSTRAINT UQ_CONECTADOS UNIQUE (CON_NOMBRE);

¿Por qué?

Porque de esa manera no tendremos que verificar nosotros que un usuario no se conecte más de una vez, el Firebird hará esa tarea por nosotros.

Si no tuviéramos esa restricción Unique Key entonces tendríamos que buscar el nombre del usuario en la tabla CONECTADOS y si existe allí entonces lanzar una excepción para evitar que se conecte. Pero al tener la restricción no es necesario que hagamos eso, ya que el mismo Firebird lanzará automáticamente la excepción. O sea, nos ahorramos trabajo.

En un trigger de la Base de Datos que se dispara cuando alguien se conecta haríamos el intento de insertar una fila en la tabla CONECTADOS, algo como:

CREATE TRIGGER INSERTAR_CONECTADO
   ACTIVE ON CONNECT
   POSITION 2
AS
BEGIN

   INSERT INTO CONECTADOS
              (CON_IDENTI, CON_NOMBRE , CON_TIMEST)
       VALUES (0 , CURRENT_USER, CURRENT_TIMESTAMP);

END;

Si el nombre del usuario no existe en la tabla CONECTADOS entonces se conectará sin problemas, pero si existe entonces el Firebird lanzará una excepción «violation of PRIMAY or UNIQUE KEY constraint …»

Y como lanzó una excepción el usuario no podrá conectarse.

No debemos olvidarnos de crear otro trigger de la Base de Datos, el que se encargará de borrar la fila que le corresponde al usuario de la tabla CONECTADOS, sería algo como:

CREATE TRIGGER BORRAR_CONECTADO
   ACTIVE ON DISCONNECT
   POSITION 3
AS
BEGIN

   DELETE FROM
      CONECTADOS
   WHERE
      CON_NOMBRE = CURRENT_USER;

END;

Entonces, cuando el usuario se desconecta la fila con su nombre será borrada de la tabla CONECTADOS.

¿Y qué ocurre si se apagó anormalmente la computadora donde se encuentra el Servidor del Firebird?

Si las cosas se hacen bien y como corresponde entonces la computadora donde se encuentra el Servidor del Firebird jamás debería apagarse intempestivamente, debería tener sí o sí una UPS en buen estado y nunca se apagaría esa computadora si hay alguien conectado a la Base de Datos.

Pero sabemos que no siempre las cosas se hacen correctamente. En ese caso los usuarios que hubieran estado conectados a la Base de Datos no podrán volver a conectarse y se requerirá que otro usuario, alguien que no estaba conectado, borre los nombres de dichos usuarios de la tabla CONECTADOS.

Luego de eso ya podrán conectarse nuevamente.

Ventaja adicional:

Este método además de evitar que un usuario se conecte más de una vez también tiene la ventaja de que siempre podremos saber quienes son TODOS los usuarios conectados.

CONECTADOS2

Captura 2. Si haces clic en la imagen la verás más grande

Como podemos ver en la Captura 2. un simple SELECT nos dirá los nombres de cada usuario conectado y también la fecha y hora de su conexión.

Conclusión:

Si queremos evitar que un usuario se conecte más de una vez a la Base de Datos y al mismo tiempo entonces podemos crear una tabla y dos triggers: uno que se disparará cuando intenta conectarse y el otro que se disparará cuando se desconecta.

De esta manera solamente podrá conectarse una vez. Tendrá que desconectarse para luego volver a conectarse.

Adicionalmente este método tiene la ventaja de que en cualquier momento podremos saber quienes son los usuarios conectados y cuando se conectaron.

Artículos relacionados:

Como evitar que se conecten a una Base de Datos

Impidiendo la conexión a una Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21