login y password

[Giniromero]

Hola a todos,

Después de ver como, al pasar una aplicación de paradox 7 a interbase 7, con delphi 6, intentando reproducirla lo más fielmente posible, lo que he conseguido ha sido crear una aplicacion muy, muy lenta... he decidido intentar crearla con nuevas directrices, lo cual me plantea varias dudas, por lo que necesito vuestra ayuda.

1) Necesito poder cambiar la información acerca del directorio donde se encuentra mi base de datos, sin tener que compilar el programa tras modificar la propiedad DataBaseName del IBDataBase, cada vez que quiera cambiarlo, ¿alguna sugerencia? Hasta ahora lo hacía escribiendo el path en un archivo txt, del que tomaba los datos desde delphi, pero esto me parece poco "elegante".

2) En la aplicación, cada usuario tiene que tener su propio login-password, que tienen que escribir al iniciar el programa. Se que interbase te da la posibilidad de tener distintos roles, asignados a los usuarios, con sus correspondientes permisos... y que en el IBDataBase de delphi, con la propiedad LoginPrompt, estando como true, hace que pida el programa el login y la password al conectar la base de datos, pero sólo me funciona bien si introduzco el usuario sysdba, las demás no me las valida.

En cualquier caso, necesito llevar un control de lo que cada usuario va haciendo en el programa. Hasta ahora, lo que tenía era una tabla con los distintos usuarios. En base a esta tabla, los usuarios se validaban, o no, para abrir el programa, y según los datos que en ella aparecían, así podían acceder o no a determinadas tablas. El login activo se guardaba, cada vez que se hacía una transacción, en un campo, que para ello tienen las tablas. ¿hay alguna opción que me guarde un registro de lo que hacen los distintos usuarios, utilizando los users-password definidos en interbase?¿alguna forma de guardar el usuario de interbase con el que se ha entrado en la base de datos, como valor para un campo de las tablas?

3) ¿hay alguna manera de que cuando el loginprompt esté en true, además de user y password, se muestre el campo ROLE ?

4) Los permisos "reference" de interbase, ¿que función tienen?

Muchas gracias, de antemano por todo.

Virginia

[triskel]

Hola Giniromero,

Solo te puedo ayudar con tu primera pregunta.
Yo veo 2 opciones para que puedas cambiar la información del directorio de tu base de datos.

La primera es usar un fichero .ini, lo que equivale lo que estas haciendo.

La seguna es almacenar la información en la base de registro, el inconveniente es que tus usuarios no deberian "fuchicar" en ella.

Espero que te sirva, un saludo

[Giniromero]

Hola,

¿a que te refieres con esto?

almacenar la información en la base de registro

Gracias,

Virginia

[guillotmarc]

Posteado originalmente por Giniromero
1) Necesito poder cambiar la información acerca del directorio donde se encuentra mi base de datos, sin tener que compilar el programa tras modificar la propiedad DataBaseName del IBDataBase, cada vez que quiera cambiarlo, ¿alguna sugerencia? Hasta ahora lo hacía escribiendo el path en un archivo txt, del que tomaba los datos desde delphi, pero esto me parece poco "elegante".

Como te han comentado, pón el path en un archivo .ini, es practicamente lo mismo que hacias, pero más "elegante"

2) En la aplicación, cada usuario tiene que tener su propio login-password, que tienen que escribir al iniciar el programa. Se que interbase te da la posibilidad de tener distintos roles, asignados a los usuarios, con sus correspondientes permisos... y que en el IBDataBase de delphi, con la propiedad LoginPrompt, estando como true, hace que pida el programa el login y la password al conectar la base de datos, pero sólo me funciona bien si introduzco el usuario sysdba, las demás no me las valida.

Yo prefiero crear una tabla en la base de datos, con los usuarios y contraseñas, así como el grupo al que pertenecen. De forma que la conexión a la base de datos la hago con SYSDBA, y una vez conectado compruebo que el usuario que han entrado exista. El tema de los permisos los comprueba el programa, en fución del grupo al que pertenece el usuario le dejas entrar o no en cada formulario.

En cualquier caso, necesito llevar un control de lo que cada usuario va haciendo en el programa. Hasta ahora, lo que tenía era una tabla con los distintos usuarios. En base a esta tabla, los usuarios se validaban, o no, para abrir el programa, y según los datos que en ella aparecían, así podían acceder o no a determinadas tablas. El login activo se guardaba, cada vez que se hacía una transacción, en un campo, que para ello tienen las tablas. ¿hay alguna opción que me guarde un registro de lo que hacen los distintos usuarios, utilizando los users-password definidos en interbase?¿alguna forma de guardar el usuario de interbase con el que se ha entrado en la base de datos, como valor para un campo de las tablas?

La variable USER devuelve una cadena con el nombre del usuario validado (normalmente SYSDBA). Por lo que puedes hacer un Trigger en las tablas, y cada vez que haya una modificación guardar en una tabla de Registro, la fecha-hora, la tabla modificada y el usuario.

Además en Firebird 1, tienes las variable CURRENT_USER (igual a USER), CURRENT_ROLE y CURRENT_CONNECTION. Esta ultima es un entero que identifica la conexión actual. De forma que si en lugar de utilizar distintos usuarios, siempre entras con SYSDBA y utilizas una tabla de usuarios para validar la entrada, puedes guardar en la tabla de usuarios la CURRENT_CONNECTION por la que han entrado. De esta forma, en un trigger puedes saber el usuario que ha hecho el cambio a partir de la CURRENT_CONNECTION.

3) ¿hay alguna manera de que cuando el loginprompt esté en true, además de user y password, se muestre el campo ROLE ?

Que yo sepa no. Dudo mucho que sea posible.

4) Los permisos "reference" de interbase, ¿que función tienen?

No lo se.

Saludos.

[Giniromero]

Hola,

Yo prefiero crear una tabla en la base de datos, con los usuarios y contraseñas, así como el grupo al que pertenecen. De forma que la conexión a la base de datos la hago con SYSDBA, y una vez conectado compruebo que el usuario que han entrado exista. El tema de los permisos los comprueba el programa, en fución del grupo al que pertenece el usuario le dejas entrar o no en cada formulario.

Bueno, en realidad yo lo estaba haciendo así hasta ahora, usando paradox, pero creía que con la utilidad de usuarios/password de interbase, podría gestionarlo mejor.

¿hay algún motivo por el que prefieras ese método?

Muchas gracias por la ayuda en cualquier caso.

Virginia

[guillotmarc]

Hola.

Simplemente en las aplicaciones que he creado, no me ha parecido necesario, eso no quiere decir que a otra gente le haya sido util.

En mis aplicaciones, no doy acceso a la base de datos fuera del programa. Otra cosa seria si proporcionara ese acceso, por ejemple por ODBC, pongamos que para que los usuarios se hagan sus propios informes con algo como las Crystal Reports. En este caso está claro que habría que crear usuarios en la base de datos, limitando los accesos a tablas y vistas, de forma que cada usuario solo pudiese ver lo que tiene asignado.

Otra cosa es definir la seguridad dentro de la aplicación. Si simplemente hago usuarios en la base de datos, y asigno derechos sobre tablas y vistas, lo que sucederá es que cuando intenten entrar en un formulario que toca una tabla a la que no tienen derecho, saltará un error en el programa de que no puede leer. Como estos errores no són nada elegantes, hay que programar en la aplicación, de que en función de a que grupo pertenece un usuario, pueda entrar a unos formularios y a otros no.

Esto se puede programar perfectamente mediante una tabla propia de usuarios y otra de grupos. No hace falta para nada la seguridad de Interbase. Así pues, si no la vamos a utilizar, ¿ porqué definirla ? (es más laborioso crear roles y asignar derechos sobre tablas, en la seguridad integrada, que hacerlo directamente por la aplicación, sobre unas tablas propias).

Personalmente solo utilizaria la seguridad integrada de Interbase, en casos como el primero comentado, en que los usuarios acceden a la base de datos, fuera del control de nuestra aplicación.

Saludos.

[kinobi]

Hola,

Posteado originalmente por guillotmarc
Esto se puede programar perfectamente mediante una tabla propia de usuarios y otra de grupos. No hace falta para nada la seguridad de Interbase. Así pues, si no la vamos a utilizar, ¿ porqué definirla ? (es más laborioso crear roles y asignar derechos sobre tablas, en la seguridad integrada, que hacerlo directamente por la aplicación, sobre unas tablas propias).

¿Por qué no una solución mixta?. Utilizar las cuentas de usuarios InterBase y una tabla(s) de grupos en la aplicación que se corresponda con posibles "roles" de la base de datos. En función del rol se activarán o no el acceso a determinadas partes de la aplicación/base de datos.

Advierte que no critico tu solución, que además he utilizado también en varias ocasiones. Simplemente exploro otras alternativas.

Saludos.

[guillotmarc]

Hola

Por eso he comentado que depende de la aplicación. Habrá muchos casos en que valdrá la pena implementar la seguridad de ese modo. Pero en aplicaciones completamente cerradas ¿ crees que vale la pena ?.

Si solo acceden a los datos a traves de la aplicación, no veo ninguna ventaja que en la base de datos hayan roles definidos. Además si definimos los roles y usuarios, habrá que asignar derechos sobre las tablas, y no me parece que valga la pena el esfuerzo que eso lleva (si alguien no debe poder entrar en unos datos, lo vamos a detener en la aplicación, antes de que salte un error del motor de Firebird).

Otra cosa es si realmente van a servir para algo los roles y definición de seguridad que hayamos hecho (cuando le damos un acceso al usuario, fuera de la aplicación). En este caso, si que me parece muy recomendable buscar un sistema de seguridad mixto (definiciones de formularios a los que se puede entrar por un lado, y seguridad integrada de Firebird por otro, todo en base a grupos relacionados con los roles creados en la base de datos).

Por cierto, si me permites una pregunta. ¿ Sabes si hay alguna forma rápida de dar acceso total a la base de datos a un usuario ?. Es que he creado un motor de replicación, y durante la replicación me conecto con un usuario distinto, para que los triggers actuen en consecuencia. Por ahora le he dado accesos a las tablas, una a una, pero quedaría mucho mejor si de alguna forma pudiese indicar que el usuario tiene los mismos derechos que el SYSDBA, o algo parecido.

Saludos.

[kinobi]

Hola,

Posteado originalmente por guillotmarc
Por eso he comentado que depende de la aplicación. Habrá muchos casos en que valdrá la pena implementar la seguridad de ese modo. Pero en aplicaciones completamente cerradas ¿ crees que vale la pena ?.

Planteado así, y desde un punto de vista técnico, probablemente no, pero ¿cuántas veces los requisitos (funcionales, acceso, ...) de un sistema cambian "mágicamente" de un día para otro cuando ya has tomado decisiones técnicas como las que debatimos?. Por eso lo que llamamos "solución mixta" me parece más "universal".

Posteado originalmente por guillotmarc
Por cierto, si me permites una pregunta. ¿ Sabes si hay alguna forma rápida de dar acceso total a la base de datos a un usuario ?.

Con una (única) sentencia "mágica", ni idea. En principio creo que la mejor solución serían los roles (again Crear un rol "administrador" y asignarlo a los usuarios "privilegiados". Habría que asignar seguramente un montón de permisos, pero sólo se haría una vez.

Saludos.

[guillotmarc]

Hola

Gracias, es lo que me temia cuando miré la sintaxis del GRANT. En efecto parece una buena idea crear un rol, puesto que la replicación ya me está provocando otro caso en el que me interesaria que se haga un tratamiento especial (por ahora hago que los triggers comprueben el USER)

Saludos.

[Giniromero]

Gracias a los dos,

Vuestros comentarios me han aclarado muchas cosas.

En cualquier caso, definitivamente he optado por algo muy similar a lo que tenía en un principio, pues he visto que es lo más practico para el tipo de aplicación que tengo.

Lo dicho, que muchas gracias.

Virginia