Control de acceso a programas. Adaptación a la LOPD.

Saludos a todos.

Hace poco me tuve que enfrentar al desafío de adaptar una aplicación mía hecha con Velneo a la normativa de la LOPD ( Ley Orgánica de Protección de Datos, en España ). Esta ley, exige entre otras muchas cosas un control de acceso a las aplicaciones, los válidos y los no válidos, guardando en un fichero Log tanto los intentos de acceso exitosos como los fallidos, con una serie de datos como la IP desde donde se realizó el acceso, el nombre de usuario y contraseña, la fecha y la hora.

También es obligado el cambio de contraseñas de acceso cada X tiempo, poder hacer listados de accesos, llevar un control de quién accede a la información catalogada como de nivel máximo, cambiante según el objetivo de cada empresa…..

El vServer nos ofrece la aplicación del Historial del Servidor, pero no se adapta por completo  a las exigencias de la Ley. Por ello, tras varias reuniones con el asesor, me dí cuenta de que el control de acceso lo tenía que hacer yo mismo desde el mismo mapa de la aplicación.

Después de meditarlo un tiempo, me puse manos a la obra para resolver todos los requerimientos y me dispongo a compartir mi experiencia con vosotros.

El esquema de tablas que planteo es el siguiente:

Esquema de tablas para control de accesos a aplicación

  1. Tabla USUARIOS: maestra. En ella se guarda el nombre del usuario, su contraseña y el nivel de acceso a la aplicación
  2. Tabla PERMISOS.: maestra. En ella se guarda a qué tiene permiso el usuario. Partí del ejemplo de acceso a menús que pueden tener los distintos usuarios de la aplicación.
  3. Tabla FLAGS: histórica de las dos anteriores. Siguiendo la forma de llamar a los permisos en Velneo, le puse el mismo nombre que la función  fUserFlag. Tiene además un campo booleano para indicar si el usuario tiene permiso o no.
  4. Tabla HCONT: histórica de USUARIOS. Permite llevar un histórico de los cambios de contraseña. Se guarda en ella la fecha de entrada en vigor de la contraseña. Se pueden ampliar el número de campos para indicar la fecha de caducidad, avisos…..
  5. Tabla BOARDS: maestra. En ella se registran las tablas de la aplicación. Hay que introducir los datos a mano, lo siento. Es una lástima que el API de Velneo no sea del todo satisfactorio como para evitar estas cosas y hacerlas de una manera más elegante.
  6. Tabla BOARD USERS: histórica de USUARIOS  y de BOARDS.  Con campos booleanos para poder establecer unas operaciones mínimas como lectura, escritura, modificación y borrado. En este ejemplo no he puesto nada de esta tabla, pues excedería el objetivo de la entrada.
  7. Tabla ACCESOS: maestra. Usada para llevar un registro de los intentos de acceso a la aplicación y si estos han sido correctos o fallidos.
  8. Tabla LOG: histórica. El log propiamente dicho y que servirá de cajón de sastre donde registrar todo lo que queramos , desde un alta hasta una modificación pasando por la ejecución de un proceso.
  9. Tabla MEM: maestra en memoria. Me sirve de base para pedir usuario y contraseña con un formulario.

Tabla histórica del LOG

Para llevar a cabo el control de acceso a la aplicación, en el menú AUTOEXEC he puesto el proceso siguiente como proceso On-init, con el que se controla el usuario, la contraseña, se hacen las comprobaciones, se registra el acceso o intento de acceso y se da el privilegio establecido al usuario.

Proceso control de usuario 2

Con ello guardamos en variables globales en memoria los datos de código de usuario $USER-CODE$ e  ip de acceso $USER IP$ que nos dan toda la información necesaria para dar de alta registros tanto en la tabla ACCESOS  como en la tabla LOG, usando la función siguiente, desde donde se estime oportuno.

A modo de ejemplo, he llamado a esta función desde dos procesos anteriores al botón Aceptar de dos formularios, el de alta de Usuarios y desde el alta de Permisos, pero se puede usar desde un trigger o proceso de tabla o desde cualquier otro proceso ( pérdida de foco, anterior o posterior a botón con acción aceptar o eliminar o….)

En el menú PRINCIPAL  he puesto dos opciones que no disparan ninguna acción, aunque podrían, pero que tienen condición de visibilidad utilizando una función a la que pasándole los parámetros de _usuario y _menu , busca en la tabla FLAGS si el usuario tiene o no autorización a ver ese menú u opción de menú.

¿Está el usuario autorizado a ver esta opción?

Con ella controlamos  la condición de visibilidad de una opción del menú ya que nos retorna el campo AUTORIZADO (booleano) para ese usuario y esa opción.

No he puesto en el ejemplo que os podéis descargar, las opciones y objetos que se utilizan para el control de acceso a tablas con la tabla BOARD-USERS. Si un hombre tiene hambre, no le des sólo un pez, enséñale a pescar.

Un saludo y espero que os guste.

P.D: el usuario por defecto que he puesto tiene los datos

  • Nombre de usuario: superusuario
  • Contraseña: hola

Búsqueda y arrays, una forma de hacer multibúsquedas (y II)

Intentaré explicar con otro ejemplo una nueva forma de hacer multibúsquedas en una tabla de datos usando de nuevo los arrays de Velneo.

El planteamiento es sencillo pero suficiente para desarrollar dos formas de hacer una multibúsqueda sobre una misma tabla: una con una rejilla en la que escogemos los datos de quién queremos mostrar de dentro de una lista de ellos y otra en la que introducimos nosotros los datos como si fuese un histórico.

Tenemos dos tablas, una de CLIENTES  y otra de VISITAS,  ésta última histórica de la primera, en la que iremos guardando las visitas que le hacemos a cada cliente en diferentes fechas. No he querido crear más campos para que el ejercicio fuera lo más sencillo y claro posible.

Esquema inicial de tablas

Esquema inicial de tablas

Primer planteamiento: el objetivo es que la aplicación busque todas las visitas que se han hecho a los clientes que yo elija en una rejilla en la que me muestra todos los clientes. Es lo que he llamado en el mapa visitas múltiple  selección y los objetos usados se guardan en la carpeta del mismo nombre.

He creado una tabla DUMMY  en memoria que se va a cargar con todos los clientes cada vez que se necesite a través de un tubo de lista.

esquema dummy

Esquema de tablas con CLIENTES, VISITAS y DUMMY

Con un formulario especial de la tabla VISITAS donde se muestra una rejilla con todos los DUMMY,  editable en su campo %ESCOGER%,  que en principio vale 0, pero que podemos cambiarlo en esa rejilla a 1 para que nos  busque las VISITAS  a ese CLIENTEDUMMY. Tras tener escogidos los CLIENTES  que queremos el proceso utiliza una cesta de VISITAS  y la potencia de los arrays, para ir cargando en la cesta las visitas de cada uno de los CLIENTES seleccionados y mostrarlos al final en una rejilla de la tabla VISITAS. Como se puede observar, la tabla DUMMY  no tiene ningún tipo de conexión con las otras dos tablas.

proceso multi

Proceso con DUMMY y "multiselección".

En el proceso se crea una cesta local de visitas donde se irán añadiendo las visitas de los CLIENTES  elegidos.

Se vacía la DUMMY   y  se rellena posteriormente mediante un tubo de lista con todos los clientes. Se crea el array.

A continuación se muestra un registro de VISITAS en el que hay una rejilla con los datos de la DUMMY. El primer campo %ESCOGIDO% es editable y se puede cambiar su valor de o a 1.

Se carga la lista DUMMY  por el índice “escogido” ( formado por el código y con campo condición para indexar %ESCOGIDO% igual a 1 ) y se van añadiendo al array los códigos de los clientes guardados en el campo %CODIGO%  de la tabla DUMMY.

Por último se caga el array, y se va leyendo cada item, que irá modificando la variable global en memoria $COD-CLIENTE$ para así lanzar la búsqueda VISITAS-COD-CLIENTE  y añadir los resultados obtenidos a la cesta. Por último se muestra la cesta.

Este planteamiento se lanza en la opción de menú búsqueda múltiple con rejilla editable

Segundo planteamiento. el objetivo es que la aplicación busque todas las visitas que se han hecho a los clientes que yo haya introducido en una rejilla. Es lo que he llamado en el mapa visitas múltiple  dando altas y los objetos usados se guardan en la carpeta del mismo nombre.

He creado una tabla DUMMYDOS  en memoria  a la que se van a añadir los clientes que se quiera mediante un formulario de alta

esquema con dummydos

Esquema con CLIENTES,VISITAS y DUMMYDOS

Esta vez DUMMYDOS si que actúa como histórica de CLIENTES, pues necesito rellenar esta tabla con un localizador y para ello , necesito que CLIENTES sea maestra de DUMMYSDOS.

El proceso llamado varía un poco, pero también creo que es sencillo y fácil de comprender.

proceso dummydos

Proceso que alimenta la cesta de las visitas

En este caso, cuando se recorre la lista de DUMMYDOS,  el dato que se debe añadir al item del array es el puntero al CLIENTE, que guarda el campo %CODIGO% de la ficha del maestro CLIENTES.

El segundo  planteamiento se lanza en la opción de menú búsqueda múltiple con rejilla “alimentada”

Seguro que es mejorable, pero es sólo un ejercicio para ver cuánto partido le podemos sacar a Velneo.

Link de descarga del mapa completo y en el foro de Velneo.

EDICION (8-sep-2010)

Tal y como me comenta por e-mail mi compañero y sin embargo amigo 🙂 Adelo Herrero el primer planteamiento se puede hacer sin la tabla DUMMY  usando la misma tabla de CLIENTES para simular la multiselección con el campo %ESCOGIDO%.

Tienes toda la razón Adelo. Se agradece el comentario y subo al link de descarga la versión actualizada con tu sugerencia.

Un saludo.

A %d blogueros les gusta esto: