Descubra aquí, cómo, en los procesos web, puede proteger sus recursos (datos + lógica de negocio) de accesos maliciosos y de usuarios no autorizados… en un solo clic.
En modo de desarrollo, establezca la propiedad Restringir acceso por defecto en FALSE para concentrarse en la organización de su código, modelo de datos, arquitectura de páginas Qodly, pruebas … sin ninguna restricción para utilizar datos o llamar a funciones.
Cuando esté listo para implementar los perfiles de usuario, simplemente establezca la propiedad Restringir acceso por defecto en TRUE para asegurarse de que nadie accederá a sus datos y lógica de negocio sin estar explícitamente autorizado.
Recordatorio
Desde 4D 20, 4D ofrece un sistema poderoso y totalmente personalizable para proteger los recursos (datos + lógica de negocio) de usuarios no autorizados.
Este sistema ofrece un nivel de granularidad personalizable y se basa en la presencia de privilegios en la sesión. Los privilegios deben estar configurados en el archivo roles.json y autorizados para ejecutar algunas acciones (Leer, Crear, …) sobre algunos recursos (clases de datos, atributos, funciones).
Los privilegios se aplican en procesos web que utilizan sesiones web escalables, por ejemplo: Peticiones REST, almacenes de datos remotos, aplicaciones Qodly.
Cuando se concede al usuario la entrada a la aplicación, la implementación de autenticación debe poner los privilegios apropiados en la sesión.
Entonces, cuando la aplicación recibe una petición web, se realiza un control sobre la presencia de privilegios en la sesión. Sólo se pueden realizar las acciones autorizadas.
Se genera un error de permiso si la acción sobre el recurso no está permitida.
la propiedad restringir el acceso por defecto
Con 4D21, una nueva propiedad booleana está disponible en el archivo roles.json: restrictedByDefault.
Permite configurar el comportamiento por defecto en lo que respecta a los accesos web a los recursos que se indican a continuación:
- el datastore
- una clase de datos
- un atributo
- una función de clase de modelo de datos
- una función singleton
Esto sólo afecta a los recursos para los que no se han establecido permisos.
Si es FALSE: los recursos son accesibles por defecto
Si no configura ningún permiso, todos sus recursos son accesibles con respecto a cualquier acción Crear, Leer, Actualizar…
Si configura permisos, todos sus recursos no implicados en permisos permanecen accesibles.
Si es TRUE: el acceso a los recursos está restringido por defecto
Si no configura ningún permiso, nada de sus recursos es accesible.
Si configura permisos, todos sus recursos no implicados en permisos permanecen inaccesibles.
La interfaz Qodly Roles y privilegios
Es posible que ya haya utilizado la interfaz Roles y privilegios de Qodly studio. Ofrece una interfaz de usuario fácil de usar para configurar los permisos para su aplicación. Esta interfaz ofrece ahora la posibilidad de actualizar la propiedad Restringir el acceso por defecto.
con versiones anteriores de 4D
Si su aplicación se ejecuta con una versión anterior de 4D, es equivalente a tener restrictedByDefault en FALSE. Puede obtener un nivel de seguridad similar creando un privilegio all, concedido para ejecutar todas las acciones en el Datastore.
Y nunca dar este privilegio all a ningún usuario.
Inicio de un nuevo proyecto
Cuando se crea un nuevo proyecto, el archivo roles.json se configura tal cual:
Debido a que restrictedByDefault es False, esto ayuda a comenzar un nuevo desarrollo. Puede concentrarse en su código, diseño de formularios, llamadas a funciones y acceder a sus datos sin obstáculos.
mejor práctica
Para una seguridad óptima, cuando esté listo para implementar perfiles de usuario, le recomendamos establecer la propiedad restrictedByDefault en True y configurar los privilegios para garantizar que:
– sus recursos están protegidos contra accesos maliciosos externos
–a cada usuario se le concede ejecutar sólo las acciones autorizadas sobre los datos permitidos
ejemplo
En el siguiente ejemplo, el modelo de datos es:
En el archivo roles.json:
así:
– es imposible acceder a la clase de datos SecretInfos (Leer, Crear, Actualizar, …)
– se requiere el privilegio viewPeople para leer la clase de datos People, otras acciones sobre la clase de datos People no están permitidas.
El IDH adjunto lo demuestra.
No espere a configurar los permisos para asegurar su aplicación y sus datos mientras maneja perfiles de usuario precisos y apropiados.