Nous avons récemment fourni une nouvelle façon de contrôler l’accès à l’API REST via les privilèges et la fonction ds.authentify: Force Login. Cette fonctionnalité offre bien plus que les mécanismes d’authentification précédemment disponibles, et a été clairement expliquée dans ce billet de blog.

Avec 4D 20 R6, Force Login est maintenant le mode par défaut pour les authentifications REST. Vous vous demandez pourquoi et comment gérer cette transition ? Continuez à lire cet article.

Mode par défaut dans les nouveaux projets

Lorsque vous créez un projet dans 4D 20 R6, un fichier roles.json est automatiquement créé dans le dossier Sources. Ce fichier inclut l’attribut forceLogin défini à« True » et un privilège« none« , qui interdit par défaut l’accès à l’API REST dans son intégralité.

Cette approche garantit un haut niveau de sécurité par conception.

Vous pouvez personnaliser les permissions en modifiant le fichier roles.json fourni ou en utilisant l’éditeur de rôles et privilèges de Qodly Studio pour une expérience plus conviviale.

Vous êtes maintenant en mesure de contrôler finement l’accès REST à vos données et fonctions !

Qu’en est-il des projets existants ?

Pour les projets existants, un nouveau bouton dans l’onglet Web/Web Features de la boîte de dialogue Structure Settings vous permet de convertir votre projet en Force Login.

En cliquant sur ce bouton, 4D :

• Supprimera des paramètres le groupe d’utilisateurs ayant un accès en lecture/écriture à l’API REST.
• Déplacera la méthode de base de données « On REST Authentication » dans la corbeille du système.
• Créera un fichier « roles.json » dans le dossier Sources s’il n’existe pas déjà, en réglant son attribut forceLogin sur True.

 

N’oubliez pas de redémarrer votre projet après avoir effectué cette conversion. Si le bouton ne s’affiche pas, votre projet est déjà compatible avec Force Login.

CONVERSION des anciens paramètres À force login

Jusqu’à l’introduction de Force Login, vous disposiez de trois options pour le contrôle d’accès REST. Nous vous expliquons ci-dessous comment les imiter toutes lorsque Force Login est activé.

Dans ces exemples, nous utiliserons un privilège « Administrator » créé dans l’éditeur de rôles et privilèges de Qodly Studio :

1 : Serveur exposé en tant que Rest sans groupe d’accès

La première option consistait à exposer le serveur REST sans définir de groupe d’accès ni filtrer les requêtes dans la méthode de base de données « On REST Authentication ».
Pour reproduire ce comportement avec Force Login, il suffit de donner un accès complet à l’ensemble de l’API REST :

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


Notez que cette implémentation n’est pas recommandée car elle manque de sécurité. Toutes les données et fonctions sont accessibles à tous.

2 : Serveur exposé en tant que Rest avec groupe d’accès défini

La deuxième option consistait à définir un groupe d’utilisateurs 4D ayant un accès en lecture/écriture à l’API REST.
Pour reproduire ce comportement, il suffit de vérifier les informations d’identification et de donner un accès complet aux membres du groupe Read/Write qui a été défini dans la boîte de dialogue Structure Settings (le groupe « RestAccess » dans cet exemple) :

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("Administrator")
End if
End if
End if


Cette restriction sécurise l’accès aux données et aux fonctions contre les connexions malveillantes. Chaque connexion autorisée a les mêmes droits.

3 : méthode ON REST AUTHENTICATION

La troisième option consistait à vérifier les informations d’identification de l’utilisateur à l’aide de la méthode de base de données « On REST Authentication ». Cette méthode était souvent utilisée pour vérifier les accès à partir d’un système de gestion des utilisateurs personnalisé. Pour reproduire ce comportement, vous pouvez presque copier le code de la méthode « On REST Authentication » dans la fonction ds.authentify(), comme dans cet exemple.

La méthode originale « On REST Authentication » :

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


Le remplacement de la fonction « ds.authentify() » :

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


Comme pour l’option précédente, chaque connexion autorisée a les mêmes droits ; l’accès aux données et aux fonctions doit être codé par vos soins.

Niveau suivant

La puissance de Force Login réside dans le fait que vous pouvez appliquer la même logique métier et les mêmes restrictions que vous souhaitez aux connexions REST. Ceci est particulièrement vrai pour les requêtes provenant des Qodly pages, des connexions Remote Datastore ou des requêtes REST externes.
Dans l’exemple suivant, au lieu de définir le privilège « Administrator » lors de l’authentification de l’utilisateur, nous définissons simplement les privilèges stockés dans l’entité User. Cela vous permet de donner un accès précis au datastore, aux data classes, aux data class attributes et aux fonctions que vous souhaitez, et de restreindre tout le reste !

Class extends DataStoreImplementation
exposed Function authentify($credentials: Object) : Boolean
If ($credentials#Null)
var $user : cs.UserEntity:=ds.User.query("identifier = :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 conclusion

Force Login offre un contrôle précis de l’accès à vos données et fonctions à partir de l’API REST. Il vous permet de déporter la logique d’accès du code vers des permissions définies, évitant ainsi les oublis de code sur l’accès et offrant un niveau de sécurité plus fiable. Cette couche de sécurité intégrée est beaucoup plus précise car vous pouvez définir les autorisations pour chaque élément du datastore (datastore lui-même, data classes, data class attributes, fonctions), et donner à chacun d’eux des droits (créer, lire, mettre à jour, supprimer, etc.).
Définissez vos privilèges et utilisez l’éditeur de rôles et privilèges de Qodly Studio pour une expérience améliorée.
Faites part de vos commentaires sur cette fonctionnalité sur les forums 4D !