Recientemente hemos suministrado una nueva forma de controlar el acceso a la API REST mediante los privilegios y la función ds.authentify: Force Login. Esta función ofrece mucho más que los mecanismos de autenticación disponibles anteriormente, y fue explicada claramente en esta entrada de blog.

Con 4D 20 R6, Force Login es ahora el modo por defecto para las autenticaciones REST. ¿Se pregunta por qué y cómo manejar esta transición? Continúe leyendo este post.

modo por defecto en los nuevos proyectos

Cuando crea un proyecto en 4D 20 R6, se crea automáticamente un archivo roles.json en la carpeta Sources. Este archivo incluye el atributo forceLogin definido en«True» y un privilegio«none «, que niega por defecto el acceso a toda la API REST.

Este enfoque garantiza un alto nivel de seguridad por diseño.

Puede personalizar los permisos editando el archivo roles.json suministrado o utilizando el editor de roles y privilegios de Qodly Studio para una experiencia más sencilla.

Ahora puede controlar con precisión el acceso REST a sus datos y funciones.

¿Qué ocurre con los proyectos existentes?

Para los proyectos existentes, un nuevo botón en la pestaña Web/Web Features de la caja de diálogo Structure Settings le permite convertir su proyecto a Force Login.

Al hacer clic en este botón, 4D:

• Quitará de la configuración el grupo de usuarios con acceso en lectura/escritura a la API REST.
• Moverá el método de base de datos «On REST Authentication» a la papelera del sistema.
• Creará un archivo «roles.json» en la carpeta Sources si no existe ya, definiendo su atributo forceLogin como True.

 

Recuerde reiniciar su proyecto después de realizar esta conversión. Si el botón no aparece, su proyecto ya es compatible con Force Login.

Pasar de la configuración heredada

Hasta la introducción de Force Login, disponía de tres opciones para el control de acceso REST. A continuación, le explicamos cómo imitarlas todas cuando Force Login está activado.

En estos ejemplos, utilizaremos un privilegio «Administrador» creado en el editor de roles y privilegios de Qodly Studio:

1: Servidor expuesto como Rest sin grupo de acceso

La primera opción consiste en exponer el servidor REST sin definir un grupo de acceso ni filtrar las peticiones en el método de base de datos «On REST Authentication».
Para reproducir este comportamiento con Force Login, basta con dar acceso completo a toda la API REST:

Class extends DataStoreImplementation
exposed Function authentify() : Boolean
return Session .setPrivileges("Administrador")


Tenga en cuenta que esta implementación no se recomienda porque carece de seguridad. Todos los datos y funciones son accesibles a todo el mundo.

2: Servidor expuesto como Rest con grupo de acceso definido

La segunda opción consiste en definir un grupo de usuarios 4D con acceso en lectura/escritura a la API REST.
Para reproducir este comportamiento, basta con comprobar las credenciales y dar acceso completo a los miembros del grupo Lectura/Escritura que se definió en la caja de diálogo Structure Settings (el grupo «RestAccess» en este ejemplo):

Class extends DataStoreImplementation
exposed Function authentify($identifier: Text; $pwd: Text) : Boolean
If ($identifier#"")
If (Validate password($identifier; $pwd)
If (User in group($identifier; "RestAccess"))
return Session .setPrivileges("Administrador")
End if
End if
End if


Esta restricción asegura el acceso a los datos y a las funciones frente a conexiones malintencionadas. Cada conexión autorizada tiene los mismos derechos.

3: método ON REST AUTHENTICATION

La tercera opción consiste comprobar las credenciales del usuario mediante el método de base de datos «On REST Authentication». Este método se utilizaba a menudo para comprobar los accesos desde un sistema de gestión de usuarios personalizado. Para reproducir este comportamiento, casi se puede copiar el código del método «On REST Authentication» en la función ds.authentify(), como en este ejemplo.

El método original «On REST Authentication» :

#DECLARE($identifier: Text; $pwd: Text) : Boolean
If ($identifier#"")
var $user : cs.UserEntity:=ds.User.query("identificador = :1"; $identifier).first()
If ($user#Null)
If (Verify password hash($pwd; $user.pwd))
return True
End if
End if
End if


El reemplazo de la función «ds.authentify()»:

Class extends DataStoreImplementation
exposed Function authentify($identifier: Text; $pwd: Text) : Boolean
If ($identifier#"")
var $user : cs.UserEntity:=ds.User.query("identificador = :1"; $identifier).first()
If ($user#Null)
If (Verify password hash($pwd; $user.pwd))
return Session.setPrivileges("Administrador")
End if
End if
End if


En cuanto a la opción anterior, cada conexión autorizada tiene los mismos derechos; el acceso a los datos y a las funciones debe codificarse por su cuenta.

Siguiente nivel

El poder de Force Login reside en el hecho de que puede aplicar la misma lógica de negocio y restricciones que quiera a las conexiones REST. Esto es especialmente cierto para las peticiones de Qodly Pages, conexiones Remote Datastore o solicitudes REST externas.
En el siguiente ejemplo, en lugar de definir el privilegio «Administrator» cuando se autentica el usuario, simplemente definimos los privilegios almacenados en la entidad User. Esto le permite dar un acceso preciso al almacén de datos, clases de datos, atributos de clases de datos y funciones que desee, ¡y restringir todo lo demás!

Class extends DataStoreImplementation
exposed Function authentify($credentials: Object) : Boolean
If ($credentials#Null)
var $user : cs.UserEntity:=ds.User.query("identificador = :1"; $credentials.identifier).first()
If ($user#Null)
If (Verify password hash($credentials.pwd; $user.pwd))
return Session.setPrivileges($user.privileges)
End if
End if
End if


 

EN conclusión

Force Login ofrece un control preciso sobre el acceso a sus datos y funciones desde la API REST. Permite deportar la lógica de acceso del código a permisos definidos, evitando así descuidos de código en el acceso y ofreciendo entonces un nivel de seguridad más fiable. Esta capa de seguridad integrada es mucho más precisa porque puede definir los permisos para cada elemento del almacén de datos (el propio almacén de datos, las clases de datos, los atributos de las clases de datos, las funciones), y otorgar derechos a cada uno de ellos (Crear, Leer, Actualizar, Eliminar, etc.).
Defina sus privilegios y utilice el editor de roles y privilegios de Qodly Studio para una experiencia mejorada.
Comparta sus comentarios sobre esta funcionalidad en los Foros 4D.