Oracle APEX insights: “Sample Dialog” Productivity App II

Dando continuidad al anterior post, vamos a seguir investigando las características de “Sample Dialog”, una “Productivity App” que nos sirve para explorar las distintas posibilidades del uso de los diálogos en Oracle APEX. En el anterior post aún quedaban por analizar algunos elementos que se crean dentro de nuestro “workspace” cuando instalamos esta aplicación. En este post analizaremos uno de estos elementos: los “Authentication Scheme”.

 

Authentication Scheme, la posibilidad de no tener que recordar una nueva contraseña

Casi cualquier compañía tiene muchas aplicaciones propias que su personal utiliza para llevar a cabo su trabajo diario. Normalmente, por cada aplicación, los empleados disponen de un usuario y una contraseña diferentes. Esto conlleva muchas veces una mala gestión de las contraseñas por parte de los usuarios (por ejemplo, apuntarlas en post-its), además de la necesidad por parte de los gestores de la aplicación de mantener estas contraseñas “a salvo”.

 

Para resolver este problema Oracle APEX incluye algunos tipos de autentificación implementados. Esto permite integrar la aplicación dentro de sistemas de autentificación ya existentes en la empresa y ahorrar la creación de cuentas de usuario nuevas. Por supuesto, también permite la autentificación independiente, y puede permitir el acceso a las aplicaciones a través del sistema de cuentas y roles de APEX.

 

Algunos de los tipos ya implementados son el LDAP, Social Sign-in, el SSO de Oracle… Pero no sólo esto: Oracle APEX también nos permite definir tipos personalizados de autentificación.

 

 

 

Las posibilidades ofrecidas para crear nuestro propio método de autentificación son múltiples: podemos definir una función que sirva para detectar si la sesión es válida o no a través de “Sentry Function Name”; nos permite decidir qué hacer cuando una sesión no es válida a través de “Invalid Session Procedure Name”; y nos permite definir cómo actuar cuando el usuario hace log-out usando “Post Logout Procedure Name”. Como no podía ser de otra forma, también podemos definir la función de autentificación en “Authentication Function Name”. Cabe destacar que esta función debe, como requisito, tener definidos dos parámetros (p_username y p_password); eso si, la forma de tratar estos parámetros, queda a libre disposición del desarrollador.

 

 

Estas funciones anteriormente indicadas pueden encontrarse dentro de una función PL/SQL de la BBDD o por el contrario, estar especificadas dentro del bloque habilitado en la sección “Source”.

 

 

¿Dónde es mejor incluir nuestro código para las funciones de autenticación?

Aquí una vez más debe entrar nuestro criterio personal a la hora de decidir si usaremos una función de la BBDD o el bloque de código. Si bien incluir el bloque de código en esta sección facilita una mejor compresión del funcionamiento de nuestro esquema a otros desarrolladores, produce una diseminación de código a lo largo de la aplicación, que no solo dificulta la reusabilidad, sino también la localización de este código a la hora de editarlo si no se tiene una política clara de gestión de código. Por otro lado, si disponemos de varias aplicaciones y cada una usa un sistema de autentificación propio, puede ser confuso editar funciones PL/SQL guardadas en la BBDD. Esto no es sólo porque a veces dentro de la Base de Datos no tenemos acceso a un editor de código con muchas funcionalidades, si no porque podemos estar editando una función de autenticación equivocada. Esto nos puede pasar especialmente si no hemos definido una política clara de definición de nombres.

Twitter
LinkedIn
Evolución, innovación y transformación
42 especializaciones avaladas por Oracle
Nuestra propuesta de valor
Posts 100% Oracle
Sigue nuestro día a día