Je souhaite développer avec SIMPLICITE une unique application, dénommée KADICS, accessible uniquement en SaaS (Web).
J’en suis l’administratrice technique et c’est moi qui crée les utilisateurs, les groupes, etc…
Dans l’unique base de données, toutes les tables ont une zone NUMERO_CLIENT, qui permet de filtrer les données utilisables par l’utilisateur connecté.
J’aimerais vos témoignages sur l’authentification et comment faire pour qu’un utilisateur qui se connecte à l’application ne voie QUE LES DONNEES de l’entreprise CLIENT qui a acheté l’abonnement à mon outil KADICS ?
J’ai pensé à ajouter dans la fiche utilisateur le code de son entreprise, mais je ne sais pas comment faire.
D’avance merci à vous.
----description of the request----
Steps to reproduce
This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:
Technical information
Instance /health
---paste the content of your-instance.com/health---
Simplicité logs
---paste the content of the **relevant** server-side logs---
Browser logs
---paste content of the **relevant** browser-side logs---
Other relevant information
----E.g. type of deployment, browser vendor and version, etc.----
La méthode setSearchSpec permet d’ajouter une clause where SQL sur vos objets métiers afin de positionner un filtre.
Elle se définit dans le hook postLoad . Vous avez un exemple içi
Pour stocker le code client au niveau de l’utilisateur, le pattern le plus utilisé est la création d’un objet héritier de SimpleUser (Utilisateur système) qu’il est possible de surcharger (ajout du code client, service, direction…etc). Pour rappel un héritier est un objet qui a le plus souvent la même table que son père (içi m_user). Je vous invite à lire notre post sur le sujet Custom User Object.
Le code client deviendrait un attribut de votre objet spécifique utilisateur et serait accessible par un getFieldValue(…)
Vous avez également la possibilité de stocker le code client au niveau d’un paramètre système utilisateur.
C’est un pattern classique où la notion de user se raccroche à des données métier (en particulier pour mettre en place un filtrage sélectif).
Pour faire ça le plus propre c’est d’utiliser un objet métier qui hérite de l’objet système SimpleUser, ex:
Veillez à lui faire hériter de com.simplicite.objects.System.SimpleUser au niveau du code pour qu’il hérite du comportement du user standard.
Ensuite il y a plusieurs patterns pour mettre en place les filtrages “globaux” possibles en fct de votre modèle:
si la notion qui sert de filtrage se retrouve par jointure dans tous vos objets (ce qui devrait à priori être le cas dans le cas d’une application multitenant) le plus efficace c’est d’utiliser la notion de UserFilters décrit ici: Simplicité® - not found
sinon il y a toujours la possibilité de positionner dans le postLoad des objets à filtrer, des filtres “durs” (searchspecs) dans vos objets en fct du user ID connecté (qui vous permet de retrouver la notion servant pour le filtrage du user custom (dans ce cas veillez à mettre par défaut un filtrage “dur” non passant sur tous vos objets ex: 1 = 2 pour qu’un éventuel bug dans votre code ne laisse pas voir trop de choses)
Celle qui est la plus “nominal” c’est les user filters mais ça implique de bien avoir le critère de filtrage sur tous vos objets métier. Dans un modèle multitenant il y a forcément un objet “chapeau” auquel tous les objets sont directement ou indirectement reliés donc ça devrait le faire.
Cela étant dit, le choix d’une stratégie monotenant ou multitenant n’est pas qu’une question de conception, il y a des besoins (ou des exigences plus ou mons rationnlles) client où il vaut mieux cloisonner et gérer chaque client dans un “clone” isolé de l’application (qui du coup est conceptuellement plus simple car monotenant).
Le cloisonnement est l’idéal mais je me heurte au tarif d’hébergement de la base de données si chaque client a finalement sa propre base et sa propre application.
David, pouvons-nous prendre contact hors de ce forum pour en discuter plus précisément ? Je démarre avec SIMPLICITE, et je découvre les astuces possibles.
Il est toujours possible de mutualiser divers éléments de l’infra (typiquement la pratie “serveur” pour applicatif et le moteur de base de données pour les données) en fct de ses besoins et des coûts.
Je ne sais pas ce que vous visez comme type d’infrastructure cloud ou on premises mais on peut parfaitement n’avoir, par exemple, qu’un seul moteur de base de données et y cloisonner les données dans des schemas différents.
Le champ des possibles avec Simplicité est extrêmement large, il faut choisir son architecture logique et technique au regard de ses moyens mais aussi de ses contraintes, de ses enjeux à court et moyen terme, des exigences des clients, de la réglementation (ex: RGPD), etc = de très nombreux éléments entrent en ligne de compte qui ne sont pas uniquement des aspects économiques:
ex1: une application multitenant est en général plus complexe à implémenter et à maintenir et, sauf à l’avoir prévu dès la conception, beaucoup moins facilement customisable qu’une application monotenant clonable/customisable.
ex2: une interruption de service sur une infra mutualisée impacte tous les clients vs un seul client dans le cas d’infras dédiées.
