Discussion :

[Just-Soft]

Salut !

Existe-il un moyen d'avoir la liste des utilisateurs à partir de l'API firebird ou à partir d'un composant ?
d'après les recherches que j'ai effectué sur le net, le seul qui sache le faire est le composant IBCSecurityService de la compagnie DEVART.

En fouillant sur le net, j'ai trouvé ce bout de code qui, en théorie, devrait fournir la liste des utilisateurs.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var
  i: integer;
  UserInfo: TIBCUserInfo;
begin
  IBCSecurityService1.Username := 'sysdba';
  IBCSecurityService1.Password := 'masterkey';
  IBCSecurityService1.Server := 'localhost';
  IBCSecurityService1.Attach;
 
  IBCSecurityService1.DisplayUsers;
 
  for i := 0 to IBCSecurityService1.UserInfosCount - 1 do begin
    UserInfo := IBCSecurityService1.UserInfos[i];
    RzComboBox_USER.Add(UserInfo.UserName);
  end;

En exécutant ledit code, je n'ai dans la liste que "SYSDBA" !
quelqu'un sait-il pourquoi je n'ai pas tout les utilisateurs de ma BD ?

ou, peut-être qu'il y'a une autre piste pour avoir cette info ?

toute idée est la bienvenue ... merci par avance

[SergioMaster]

Bonjour,

tu parles : des utilisateurs pouvant se connecter à la base
dans le premier cas un SQL devrait le faire

Code SQL :

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

1
2
3
4
5
 
SELECT u.RDB$USER, u.RDB$RELATION_NAME
FROM RDB$USER_PRIVILEGES u
WHERE u.RDB$PRIVILEGE = 'M'
ORDER BY 1, 2

ou ceux de Firebird ?

d'après les recherches que j'ai effectué sur le net, le seul qui sache le faire est le composant IBCSecurityService de la compagnie DEVART.

je ne crois pas que ce soit le seul sans tester je pense à UIBSecurity des UIB et a TADSecurity de Firedac

[Just-Soft]

tu parles : des utilisateurs pouvant se connecter à la base
dans le premier cas un SQL devrait le faire

Code SQL :

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

1
2
3
4
5
 
SELECT u.RDB$USER, u.RDB$RELATION_NAME
FROM RDB$USER_PRIVILEGES u
WHERE u.RDB$PRIVILEGE = 'M'
ORDER BY 1, 2

ça a l'air sympa le bout de code

je teste et je donnerais suite .... merci Serge

[Just-Soft]

Re,

je pose la question autrement ... est-il plus judicieux, dans une application CS, de réaliser une table USERS dans la BD ou de restituer celle crée par firebird et stockée dans security2.fdb ?

car, sur un poste client, en listant la liste des utilisateurs connectés à ma BD Firebird depuis mon application, je me suis retrouvé avec d'autres utilisateurs et qui ne sont pas les mêmes avec ceux du poste Serveur ?!

A priori, ça m'a paru logique, car j'avais installé Firebird sur tout les postes clients donc il a crée dans chacun des répertoires Firebird 2.5, un fichier security.fdb. Ce qui me ramène à vous demander, chers développeurs, votre solution à vous si vous êtes confronté à mon problème; allez vous créer un objet USERS dans votre base de données et le gérer indépendamment de Firebird avec tout ce qui va engendrer comme développement, en plus, pour la partie droit d'accès et rôle, ou allez-vous choisir la deuxième méthode qui est celle d'extraire les utilisateurs depuis security2.fdb ?

si vous choisissez la seconde solution, quelles est la démarche à suivre pour n'avoir qu'un seul security2.fdb sur tout les postes ?

merci encore

[SergioMaster]

Bonjour,

Déjà je ne déploie qu'un seul serveur Firebird , les utilisateurs n'ayant que le Client , ce qui répond à la question du security2.fdb je pense . S'il fallait , pour des raisons , pas forcément bonne , exceptionnelles (pour utiliser des tables de travail temporaires par exemple, mais ceci peut également se faire via des tables mémoires ou en utilisant des Global Temporary Table ) avoir besoin de mettre Firebird sur des postes clients , j'y mettrai une version Embedded

mais je suis étonné de tes résultats , si tu utilises la requête que je t'ai fourni , c'est bien sur la base de connexion que cela se passe et pas sur un security2.fdb. Faire gérer la sécurité de la base de données est très "sensible"

Ensuite pour ce qui est d'une table Utilisateur , je vais faire une réponse de normand : pour certaines applications oui pour d'autres non .
Ca n'aide pas , je sais

voila par exemple 2 cas que j'ai exploité
- une application qui se connecte en mode lecture à une BDD distante , selon le type d'utilisateur (Fournisseur/Donneur d'ordre/autre)
dans ce cas , dans la Base de Données qui contient une table utilisateur , avec un couple NOM/MDP et le type d'utilisateur
mais la base de données outre SYSDBA , à uniquement 4 autres Utilisateurs USINE/FOURNISSEUR/INTERRO/SECURITE ayant des rôles différents
je me connecte d'abord à la base en tant que SECURITE : lecture seule acces à la seule table UTILISATEUR
je contrôle alors le couple NOM/MDP puis ensuite me reconnecte à la base selon le type d'utilisateur

- une application qui se connecte en mode lecture/ecriture à une BDD distante
là , j'utilise la connexion "classique" : utilisateur/mot de passe/role de firebird

Avantage de la première à la seconde , une gestion beaucoup plus simple des utilisateurs par le client lui-même (le(s)responsable(s) chez le donneur d'ordre) , la partie rôle est totalement transparente .

de la seconde sur la première ? plus facile pour le programmeur plus sérieusement cela fait une couche de moins , après tout Firebird gère les utilisateurs pourquoi se casser la tête ?

[Just-Soft]

mais je suis étonné de tes résultats , si tu utilises la requête que je t'ai fourni , c'est bien sur la base de connexion que cela se passe et pas sur un security2.fdb. Faire gérer la sécurité de la base de données est très "sensible"

je suis plus étonné que toi
j'ai copié la BD dans un poste local et j'ai lancé la requête ... le résultat n'est pas du tout le même ?

en parlant de poste client, quel est le minimum, firebird, qui doit s'y trouvé ? d'ailleurs c'est la 1ère fois que je le fait, y'a t-il des conseils particuliers pour éviter des surprises ?

[SergioMaster]

j'ai copié la BD dans un poste local et j'ai lancé la requête ... le résultat n'est pas du tout le même ?

comment a t'elle été copié ? par copie de fichier , c'est la mauvaise solution , une bonne copie de la BD doit se faire via un backup/restore
même par la mauvaise méthode , le résultat aurait du être correct puisque l'on interroge une table système de la base et non security2.fdb

en parlant de poste client, quel est le minimum, firebird, qui doit s'y trouvé ? d'ailleurs c'est la 1ère fois que je le fait, y'a t-il des conseils particuliers pour éviter des surprises ?

sur un poste client , seule la partie cliente doit être copiée , dans les options d'installation seule l'installation du client reste coché
pour les surprises elles se situent surtout au niveau des différences entre 32 bits et 64 bits , ce que le programme d'installation sait gérer à partir du moment où l'on indique de copier les bibliothèques (fbclient.dll) dans le répertoire système ; et au niveau de GDS32.dll que par mesure de précaution il faut demander de générer (en fait ce n'est qu'une copie de fbclient.dll) je ne sais pas si IBDAC gère l'accès direct a fbclient.dll

ceci est d'ailleurs plus une question à poser sur le forum firebird que dans langage Delphi