Découvrez ici comment, dans les processus web, vous pouvez protéger vos ressources (données + logique métier) des accès malveillants et des utilisateurs non autorisés … en un seul clic.
En mode développement, mettez la propriété Restreindre l’accès par défaut à FAUX pour vous concentrer sur l’organisation de votre code, le modèle de données, l’architecture des pages Qodly, les tests … sans aucune restriction d’utilisation des données ou d’appel de fonctions.
Lorsque vous serez prêt à mettre en place des profils d’utilisateurs, il vous suffira de mettre la propriété Restreindre l’accès par défaut à VRAI pour vous assurer que personne n’accèdera à vos données et à votre logique d’entreprise sans y être explicitement autorisé.
Rappel
Depuis 4D 20, 4D fournit un système puissant et entièrement personnalisable pour protéger les ressources (données + logique métier) des utilisateurs non autorisés.
Ce système offre un niveau de granularité personnalisable et repose sur la présence de privilèges dans la session. Les privilèges doivent être définis dans le fichier roles.json et autorisés à exécuter certaines actions (Read, Create, …) sur certaines ressources (dataclasses, attributs, fonctions).
Lesprivilèges s’appliquent aux processus web utilisant des sessions web évolutives, par exemple: requêtes REST, dépôts de données à distance, applications Qodly.
Lorsque l’utilisateur est autorisé à entrer dans l’application, l’implémentation de l’authentification doit placer les privilèges appropriés dans la session.
Ensuite, lorsque l’application reçoit une requête web, un contrôle est effectué concernant la présence de privilèges dans la session. Seules les actions autorisées peuvent être effectuées.
Une erreur de permission est levée si l’action sur la ressource n’est pas autorisée.
la propriété de restriction d’accès par défaut
Avec la 4D21, une nouvelle propriété booléenne est disponible dans le fichier roles.json: restrictedByDefault.
Elle permet de définir le comportement par défaut concernant les accès web aux ressources ci-dessous :
- le datastore
- une classe de données
- un attribut
- une fonction de classe de modèle de données
- une fonction singleton
Ceci n’a d’impact que sur les ressources pour lesquelles aucune permission n’a été définie.
Si FALSE: les ressources sont accessibles par défaut
Si vous ne mettez pas en place de permissions, toutes vos ressources sont accessibles pour toute action Créer, Lire, Mettre à jour…
Si vous mettez en place des permissions, toutes vos ressources non concernées par les permissions restent accessibles.
Si VRAI: l’accès aux ressources est restreint par défaut
Si vous ne définissez pas de permissions, rien dans vos ressources n’est accessible.
Si vous mettez en place des permissions, toutes vos ressources non concernées par les permissions restent inaccessibles.
L’interface Qodly Rôles et privilèges
Vous avez peut-être déjà utilisé l’interface Rôles et privilèges de Qodly studio. Elle offre une interface conviviale pour configurer les permissions de votre application. Cette interface permet désormais de mettre à jour la propriété Restreindre l’accès par défaut.
avec les versions précédentes de 4D
Si votre application fonctionne avec une version antérieure de 4D, il est équivalent d’avoir restrictedByDefault à FALSE. Vous pouvez obtenir un niveau de sécurité similaire en créant un privilège « all », qui permet d’exécuter toutes les actions sur le Datastore.
Ne donnez jamais ce privilège à un utilisateur.
Démarrage d’un nouveau projet
Lorsque vous créez un nouveau projet, le fichier roles.json est configuré tel quel :
Comme restrictedByDefault est False, cela facilite le démarrage d’un nouveau développement. Vous pouvez vous concentrer sur votre code, la conception des formulaires, les appels de fonction et l’accès à vos données sans être gêné.
Meilleure pratique
Pour une sécurité optimale, lorsque vous êtes prêt à mettre en œuvre des profils d’utilisateur, nous vous recommandons de définir la propriété restrictedByDefault sur True et de définir des privilèges pour garantir :
– quevos ressources sont protégées contre les accès malveillants externes
– quechaque utilisateur n’a le droit d’exécuter que des actions autorisées sur des données permises
Exemple
Dans l’exemple ci-dessous, le modèle de données est le suivant :
Dans le fichier roles.json:
donc :
– il est impossible d’accéder à la classe de données SecretInfos (Read, Create, Update, …)
– le privilège viewPeople est nécessaire pour lire la classe de données People, les autres actions sur la classe de données People ne sont pas autorisées.
L’IDH ci-joint le démontre.
N’attendez pas pour mettre en place des permissions afin de sécuriser votre application et vos données tout en gérant des profils d’utilisateurs précis et appropriés.