Gestion des fichiers de répertoire dans les projets de serveurs fusionnés

Traduit automatiquement de Deepl

Projects a introduit le nouveau fichier directory.json contenant les utilisateurs, les groupes et les permissions. Il permet l’authentification, les restrictions, les permissions sur plusieurs parties de l’application, via les paramètres ou le code. Voyons les nouvelles améliorations concernant l’utilisation de ce fichier dans les projets de serveurs fusionnés.

Rappel

Sur un projet, les utilisateurs, les groupes et certaines permissions sont enregistrés dans le fichier répertoire. Pour vous rappeler comment cela fonctionne, vous pouvez relire ce blog-post de présentation ou regarder cette vidéo.

Fichiers d’annuaire

Le fichier de répertoire du projet est le fichier directory.json situé dans le dossier des paramètres utilisateur du projet (dossier Settings à côté du dossier Project du projet utilisé) :

Le fichier de répertoire des données est le fichier directory.json situé dans le dossier des paramètres utilisateur des données (dossier Settings à côté du dossier des données en cours d’utilisation) :
blank

Le fichier du répertoire de l’application est le fichier directory.json situé dans le dossier des paramètres utilisateur de l’application (dossier Settings à l’intérieur du dossier Server Database de l’application serveur fusionnée) :
blank

Intégrer le fichier pendant le processus de construction de l’application

Jusqu’à présent, c’était votre travail d’inclure un fichier de répertoire dans le serveur fusionné après le processus de construction de l’application. Si vous n’incluez pas de fichier répertoire dans le package de l’application ou à côté du fichier de données, pendant l’exécution, tous les utilisateurs utilisent le compte Designer avec tous ses droits.
Donc, pour rendre les choses plus sûres et plus faciles, à partir de la v19R5, une nouvelle clé buildApp est à votre disposition. Cette clé incorpore automatiquement le fichier du répertoire du projet dans le serveur fusionné pendant le processus de l’application build :

<BuildApp>
<CS>
<ServerEmbedsProjectDirectoryFile>True</ServerEmbedsProjectDirectoryFile>

Notez que ce nouveau paramètre est également disponible dans la boîte de dialogue Build Application :

blank

Comportement côté serveur

Le comportement actuel est maintenu : le serveur 4D charge le fichier du répertoire de données s’il existe. Sinon, le fichier répertoire de l’application est chargé.
Mais dorénavant, dans un projet de serveur fusionné, toutes les modifications apportées aux utilisateurs, groupes et permissions pendant l’exécution sont automatiquement stockées dans le fichier de répertoire de données. Le fichier du répertoire d’application n’est jamais touché et peut être considéré comme un fichier du répertoire d’initialisation. Cela garantit que la signature de votre application reste sûre sur macOS, ou vous permet de placer votre application serveur dans un dossier en lecture seule sans aucune erreur.
Au démarrage du serveur, si aucun fichier de répertoire de données n’existe, les utilisateurs, les groupes et les permissions stockés dans le fichier de répertoire d’application, s’ils existent, sont chargés. Ensuite, si des modifications sont effectuées sur les utilisateurs, les groupes ou les permissions, elles sont stockées dans le fichier du répertoire de données.

Comptes techniques

Les utilisateurs et les groupes sont souvent utilisés comme comptes techniques par les développeurs 4D. Cela peut être fait à l’aide de la boîte à outils, ou avec le code 4D en testant le nom d’utilisateur actuel avec Current user ou l’appartenance à un groupe avec User in group. Dans ce cas, pour s’assurer que ces utilisateurs et groupes sont persistants, vous pouvez les vérifier au démarrage du serveur, et les modifications ultérieures seront automatiquement enregistrées dans le fichier du répertoire de données!

Avatar
- Product Owner -Damien Fuzeau a rejoint l'équipe 4D Product en février 2019. En tant que Product Owner, il est en charge de la rédaction des user stories, puis de leur traduction en spécifications fonctionnelles. Son travail consiste également à s'assurer que les implémentations de fonctionnalités livrées répondent aux besoins des clients.Damien est diplômé de l'Université de Nantes en génie logiciel. Il a passé plus de 23 ans dans son ancienne entreprise, d'abord en tant que développeur (découverte de 4D en 1997), puis en tant que responsable de l'ingénierie et architecte logiciel. Cette société est un partenaire OEM de 4D et a déployé des logiciels d'entreprise basés sur 4D pour des milliers d'utilisateurs, sur des centaines de serveurs. Damien est donc habitué au développement et au déploiement 4D dans un contexte multi-langues.