Una mejor comprensión de las sesiones 4D REST

En una entrada anterior del blog, le mostramos cómo empezar con el servidor REST de 4D. Le guiamos a través de diferentes operaciones CRUD usando Postman y le indicamos la documentación REST completa. En esta entrada del blog, explicaremos cómo funcionan las sesiones en 4D. Esta comprensión le permitirá construir un sistema de autenticación basado en sesiones utilizando el servidor 4D REST.

Sesiones 4D rest

Si está interesado en construir un sistema de autenticación, un sistema basado en sesiones es lo que está buscando.

Las conexiones al servidor 4D REST están basadas en sesiones. Esto significa que el servidor 4D crea una sesión cuando el cliente envía la primera solicitud y le devuelve una cookie de sesión (WASID4D). Para todas las solicitudes posteriores, el cliente debe devolver esta cookie de sesión en la cabecera de la solicitud. Esto es contrario a la autenticación basada en tokens, en la que no se persigue ninguna sesión en el lado del servidor, sino que se almacena en el cliente.

Configurar el servidor REST

Ahora que tenemos una buena comprensión de cómo se manejan las sesiones, vamos a seguir adelante. Antes de empezar, es necesario iniciar y configurar el servidor 4D REST. Por favor, consulte esta entrada del blog o el centro de documentación antes de seguir adelante.

Sobre el método de autenticación REST

The On REST Authentication El método de la base de datos le proporciona una forma personalizada de controlar cómo se abren las sesiones REST en 4D. Cuando se recibe una solicitud para abrir una sesión REST, los identificadores de conexión(por ejemplo, nombre de usuario y contraseña) se proporcionan en la cabecera de la solicitud. Se llama al método de la base de datos On REST Authentication para poder evaluar estos identificadores y devolver True (apertura de sesión aceptada) o False (apertura de sesión rechazada).

Nota: Aunque este método de base de datos se utiliza para codificar su propio control de acceso a la base de datos, el acceso también puede ser restringido utilizando un grupo de usuarios 4D. Cuando exponga la base de datos, seleccione el grupo al que se le permite el acceso en la pestaña Configuración de la base de datos > Web > recurso REST. Consulte esta entrada del blog para refrescar la memoria.

Abrir una sesión

Para ilustrar la apertura de una sesión, vamos a imaginar un formulario de envío con un nombre de usuario y una contraseña. Usaremos Postman para enviar las credenciales en las cabeceras de la petición POST. Para abrir una sesión en su aplicación 4D a través de REST, utilice $directory/login:

Volvamos a 4D y veamos qué está pasando.

Como puede ver, el método de la base de datos recibe cuatro parámetros:

• $1 para el nombre de usuario,
• $2 para la contraseña,
• $3 devuelve True si la contraseña está cifrada y False si no lo está,
• $4 contiene la dirección IP de la persona que llama.

Nota: En el mundo real, las contraseñas deben estar cifradas y no enviarse en claro. Para enviar una contraseña con hash puede utilizar el parámetro hashed-password-4D en lugar de password-4D. Consulte este ejemplo de código que muestra cómo proceder.

Una vez recibida la solicitud, el servidor abre una sesión y devuelve una cookie de sesión al cliente (WASID4D):

Ahora que nuestra sesión ha sido creada, ¿cómo podemos pasar su ID de vuelta en las consecuentes peticiones HTTP?

Espera… ¿por qué tenemos que hacer esto en primer lugar?

Gestión de la sesión

HTTP es un protocolo «sin estado» … cada vez que un cliente se conecta a una página web, abre una conexión independiente con el servidor web. El servidor no guarda un registro de las solicitudes anteriores de los clientes. Imagínese que miles de clientes se conectan al servidor, ¿cómo puede saber qué sesión es la suya? Ahí es donde entra en juego el identificador de sesión. A través de este intercambio de ID de sesión, se mantiene el estado. ¿Qué significa esto exactamente? Bueno, significa que para reutilizar la misma sesión, hay que asegurarse de que todas las solicitudes REST posteriores incluyan el ID de sesión en la cabecera«Cookie» de la solicitud. De lo contrario, se abrirá una nueva sesión (y una nueva sesión significa una nueva licencia).

Ejemplo

La forma de gestionar las sesiones depende en realidad de su cliente HTTP. Digamos que estamos en un contexto en el que las peticiones se gestionan a través del comando HTTP Request.

Para incluir el ID de sesión en la cabecera, primero tenemos que encontrarlo. Es fácil. Sabemos que la sesión tiene una clave WASID4D, así que sólo tenemos que buscar esta clave en los valores de la cabecera con el comando Find in array:

Find in array($headerValues; "WASID4D@")

Una vez encontrada, vamos a extraerla:

$start:=Position("WASID4D";$cookie)
$end :=Position(";";$cookie)
$uuid := Substring($cookie;$start;$end-$start)El $uuid alojará el ID de sesión que se enviará en todas las peticiones posteriores. Encuentre el ejemplo completo aquí.

Controlar el tiempo de inactividad de la sesión

Por defecto, el tiempo de inactividad de la sesión es de 60 minutos y no puede ser menor. Sin embargo, se puede aumentar la duración del tiempo de espera con el valor del parámetro«session-4D-length» que se puede pasar en las cabeceras POST con el método $directory/login.

Una cosa más

4D Server tiene una sesión que almacena las selecciones de entidades basadas en consultas previas o comandos de pedido. Por eso cuando se necesita el siguiente «rango» (o trozo) de datos, no necesita consultar/ordenar de nuevo, simplemente necesita enviar el siguiente conjunto de datos. Este mecanismo permite el uso de transacciones, bloqueo pesimista, y más.

¿Qué es lo siguiente?

El servidor REST ha sido mejorado en gran medida con 4D v18, y más características vendrán en el futuro. Mientras tanto, seguiremos ofreciéndole ejemplos y casos prácticos de uso. No dude en unirse a la discusión en el foro de 4D.