Discussion :

[Klemsy78]

Salut,

j'ai developpé une application client/serveur en Delphi 7.
Il s'agit d'une application de gestion de projet. Il consiste à enrégistrer des projets puis de les attribuer à des conseillers projets pour étude de faisabilité.

Pour mon application j'ai pluisieurs groupes d'utilisateurs à savoir
"les Receptionnistes" chargés d'enrégitrer les visiteurs et leur projet, "le responsable des conseillers" projet chargé d'attribuer les projets "aux conseillers projet",ces derniers à leur tour verront dans leur portefeuille les projets qui leurs sont attribués et enfin "un administrateur" du système qui lui est chargé de créér les groupes d'utilisateur, les utilisateurs et de définir leurs droits d'utilisation du système( Par exemple un receptionniste ne doit accéder qu'aux formulaires d'enrégistrement de projet...).

Je voudrais savoir comment gérer les droits d'accès? J'ai besoin qu'on me donne des idées ...

Merci pour votre compréhension.....

[Lung]

Regarde par là :

http://www.developpez.net/forums/sho...NTFileSecurity

[Klemsy78]

Dans mon cas il ne s'agit pas de droit d'accès à un repertoire ou fichier.
Il s'agit de fenêtre(formulaire) pour effectuer certaines opérations .
Ce que je veux c'est que quand un utilisateur de mon logiciel se connecte qu'il est son propre menu qui sera different du menu d'un autre type d'utilisateur.

Merci.....

[Lung]

Gère les droits dans une base de données, alors ...
J'ai déjà fait çà de nombreuses fois, pour donner l'accès à différents modules d'une application, et générer des menus dynamiquement.

[Jipété]

Salut !

Dans mon cas il ne s'agit pas de droit d'accès à un repertoire ou fichier.

Le titre du topic est trompeur... (tu peux le modifier en éditant ton premier message).

(...) quand un utilisateur de mon logiciel se connecte, qu'il ait son propre menu qui sera différent du menu d'un autre type d'utilisateur.

HKCU\Software\TonAppli\Params\, c'est pas fait pour ça ?

Encore que, en relisant, il y a un truc ambigu :

d'un autre type d'utilisateur

ou

d'un autre utilisateur

?, puisque

quand un utilisateur

Mes 2 cts,
--
jp

[fthdz]

salut ,

une des solution consiste a creer 4 tables:

t_user(idu,nom,prenom,login,password,groupe,suspend)
t_groupe(idG,group_name)
t_module(idM,iINTITULE)
t_Autorisation(IdG,IdM,add,edit,del)

il faut creer des groupes (t_groupe) et definir leurs droits(t_Autorisation) sur les modules(t_module) puis l'attribuer des utilisateurs(t_user.groupe)

dans le chargement de l'application selon le login et le mot de passe le groupe sera determiné et les autorisation seront charger de la table t_Autorisation ainsi le tmainmenu sera creer dynamiquement selon les droits.

bonne chance!!

[Klemsy78]

D'abord je tiens à vous remercier pour votre réponse car elle est assez clair pour moi. Mais je veux savoir en fait que contient la table Module.
Et quel est le type du champ suspend de la table User et à quoi cela sert.
Merci........

[fthdz]

rebonjour,

Pour la table MODULE ,il contient les modules de votre projet par exemple: gestion des visiteurs, gestion des projets,gestion des utilisateurs...etc selon votre conception, puis tu doit definir les droits pour chaque module(dans la table t_Autorisation) par exemple :attribuer,editer,supprimer ..etc qui sont de type boolean T ou 1 : a le droit
F OU 0: n'a pas le droit

donc vous aurez une matrice : module groupe attribuer editer delete
modul_1 group_1 1 1 1
modul_2 group_1 0 0 1
modul_3 group_1 0 1 0

pour le champ SUSPEND est un champ de type boolean T: User est active
F: User suspendu

c'est pour permettre a l'administrateur de suspendre un utilisateur par exemple pour une periode determinée.bien sur selon votre conception tu peut ajouter d'autre champs comme date_derniere_modif,niveau =1 admin , ..tc
=2 autres

n'hesiter pas a poser d'autres questions
merci

[cantador]

Autrement dit, c'est créer une relation N-N entre
les modules et les groupes.

Je me demande si le compo UIL security ne ferait pas tout çà

??

[fthdz]

mais le composant UIL security est payant!!

[cantador]

Ben oui, je n'ai pas dit qu'il était free..
mais c'est vrai avec une telle matrice on peut s'en sortir en servant d'une fonction.

il faut penser aussi à créer une interface afin de pouvoir gérer des modifications de droit.

la limite est néanmoins atteinte si bien sûr on a besoin de créer un autre groupe avec des nouveaux droits.

Dans ce cas il faut retoucher le code..

Ah si un autre truc, je choisirai plutot les datasets(les tables) plutôt que les modules
car il est tout à fait possible d'avoir plusieurs tables dans une même forme avec des conditions d'accès diffférentes.

[swierzbicki]

Pourquoi ne pas creer une table utilisateurs en y stockant les droits ?
C´est simple et efficace. Exemple :

Utilisateur (varChar) Rubrique1 (boolean) Action1 (boolean) Action2 (boolean)....

Lors de la connection de l´utilisateur verifier les droits en rendre Visible ou actif les rubriques ou actions ...

[cantador]

@swierzbicki :
C'est quand même mieux de créer des groupes de droit
et de mettre ensuite les utilisateurs dans ces derniers qui héritent ainsi
des propriétés du conteneur.

l'information est de ce fait stockée qu'une seule fois.

Et de la même manière, si on modifie les droits d'un groupe, ce sont tous les utilisateurs de ce groupe qui héritent de la modification.

non ?

[fthdz]

re bonjour,

En réalité cette solution j utilisé pour le web( en PHP) mais je pense qu'il est valable pour le DELPHI .

il faut penser aussi à créer une interface afin de pouvoir gérer des modifications de droit.

bien sure celle ci rentre dans la phase de codage avec l'utilisation par exemple des TCheckBox...

la limite est néanmoins atteinte si bien sûr on a besoin de créer un autre groupe avec des nouveaux droits.

J pas compris vraiment votre remarque ,en effet on peut ajouter le maximum de groupe a la table t_group avec differents droits.

Pour les modules il y a differents facon de le définir ,soit par action soit par rebrique ... ou de creer nouveau table t_action lier au table module qui contient les rebrique ...etc

merci

[cantador]

J pas compris vraiment votre remarque ,en effet on peut ajouter le maximum de groupe a la table t_group avec differents droits.

Pour les modules il y a differents facon de le définir ,soit par action soit par rebrique ... ou de creer nouveau table t_action lier au table module qui contient les rebrique ...etc

Oui, bien sûr on peut ajouter des nouveaux groupes avec des nouveaux droits
MAIS, la suite ne peut pas être automatiser..
il faudra nécessairement modifier le code..
c'était le sens de ma remarque..

Si vous avez dans un module, comme cela m'est arrivé, 5 datasets dedans
pour gérer les droits sur chaque table ??
On voit bien ici que les droits d'accès à un module ne sont pas suffisants..

Pour ma part, je maintiens que le DataSet est beaucoup plus précis et plus efficace que le module.

En plus, pour l'interface, c'est également plus facile à définir et à traiter.

cantador

[colonel098]

Salut J'ai le Même problème mais je ne sais pas comment géré
Je doit crée quel combien Table et dit moi les Table qui sont en relation car je n'arrive à savoir s'il y a des relations père fils

[Just-Soft]

Salut !

dans la base de données, on peut très bien songer à créer des roles (groupe), et des utilisateurs puis dans l'application, par simple code sql on peut avoir la liste des utilisateurs avec leur roles. Les roles sont fait pour donner des droits sur les tables donc les modules. Je crois que cette façon de faire permet de ne pas ajouter d'autres tables inutilement.

dans l'application, tout ce qui reste à faire, c'est de définir au lancement ce qui doit être affiché ou pas, activé ou pas, etc et cela suite à la paire (user, pw) choisis.

cette ligne de code permet d'afficher ou non un dbnavigateur selon le role (groupe) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cxDBNavigator_SR.Visible := (PasswordDlg.PROFIL <> 'CONSULTATION');

dans le Oncreate de la fenêtre principale on peut aussi choisir ce qui peut être afficher :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// Activation du menu Administration selon l'utilisateur connecté
  AdministrationBDD_GEXP.Visible := (DM.IBCConnection1.Username = 'ADMIN');
  Menu_Profil := (DM.IBCConnection1.Username = 'ADMIN')
    or (PasswordDlg.PROFIL = 'MAJ_BD');
  Importer_XLS.Enabled := Menu_Profil;
  Exporter_XLS.Enabled := Menu_Profil;
  Paramtrage.Enabled := Menu_Profil;
  Unite.Enabled := Menu_Profil;
  Centre.Enabled := Menu_Profil;
  commune.Enabled := Menu_Profil;
  Station_epuration.Enabled := Menu_Profil;
  Station_relevage.Enabled := Menu_Profil;

espérant que cela peut vous servir.

[colonel098]

Salut !

dans la base de données, on peut très bien songer à créer des roles (groupe), et des utilisateurs puis dans l'application, par simple code sql on peut avoir la liste des utilisateurs avec leur roles. Les roles sont fait pour donner des droits sur les tables donc les modules. Je crois que cette façon de faire permet de ne pas ajouter d'autres tables inutilement.

dans l'application, tout ce qui reste à faire, c'est de définir au lancement ce qui doit être affiché ou pas, activé ou pas, etc et cela suite à la paire (user, pw) choisis.

cette ligne de code permet d'afficher ou non un dbnavigateur selon le role (groupe) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cxDBNavigator_SR.Visible := (PasswordDlg.PROFIL <> 'CONSULTATION');

dans le Oncreate de la fenêtre principale on peut aussi choisir ce qui peut être afficher :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// Activation du menu Administration selon l'utilisateur connecté
  AdministrationBDD_GEXP.Visible := (DM.IBCConnection1.Username = 'ADMIN');
  Menu_Profil := (DM.IBCConnection1.Username = 'ADMIN')
    or (PasswordDlg.PROFIL = 'MAJ_BD');
  Importer_XLS.Enabled := Menu_Profil;
  Exporter_XLS.Enabled := Menu_Profil;
  Paramtrage.Enabled := Menu_Profil;
  Unite.Enabled := Menu_Profil;
  Centre.Enabled := Menu_Profil;
  commune.Enabled := Menu_Profil;
  Station_epuration.Enabled := Menu_Profil;
  Station_relevage.Enabled := Menu_Profil;

espérant que cela peut vous servir.

Je suis d'accord avec ta methode mais le problème je ne sais pas comment je vais m y prendre avec FireBird et Delphi