pb de création d'utilisateurs [FAQ]

[devalender]

BONJOUR A TOUS

j'ai en effet un pb avec les nouveaux utilisateurs que je crée en effet
j'ai une base de données avec 12 tables.
lorsque je crée un nouvelle user avec un mot de passe l'opération se
passe sans problème.
lorsque je tente d'accerder aux tables avec se nouveau user/password
j'ai le message suivant pour toutes les tables!

Code :

1
2
3
 
this user does NOT have privilege TO perform this operation
ON this object. no permission FOR READ/SELECT TO TABLE matable

et ce message se repète pour toutes ces tables lorsque je tente
d'acceder aux données.

pour information voici comment je crée mon user/password

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
procedure Tadduse.Button1Click(Sender: TObject);
begin
 WITH IBSecurityService1 do
  begin
  ServerName := 'Poulet';
  LoginPrompt := False;
  Params.ADD('user_name=sysdba');
  Params.ADD('password=masterkey');
   Active := True;
    try
      UserName := Edit1.Text;
      Password := Edit2.Text;
      UserID := StrToInt(Edit4.Text);
      GroupID := StrToInt(Edit5.Text);
      AddUser;
      finally
    Active := False;
    end;

ensuite avec ce code je donne les droits suivants a mon_user

Code :

1
2
3
4
5
6
7
8
9
10
11
 
procedure Tadduse.Button6Click(Sender: TObject);
var
begin
 WITH ibQuery1 do
begin
Close;
SQL.Clear;
SQL.ADD('GRANT ADMINROLE TO MON_USER');
ExecSQL;
end;

ADMINROLE est un role que j'ai crée avec IBconsole et je lui donné les
droits suivants:

Code :

1
2
 
GRANT SELECT, DELETE, INSERT, UPDATE ON table1,...table12   TO adminrole

en fait j'ai repeté ce code pour toutes les tables.

Par la suite je crée un autre user sur Ibconsole et lorsque j'essai d'acc
aux tables avec ce nouveau user j'ai encore le même message

Code :

1
2
3
 
this user does NOT have privilege TO perform this operation
ON this object. no permission FOR READ/SELECT TO TABLE matable

et cela pour toutes les tables.

en cherchant sur le forum j'ai vue le code suivant:

Code :

1
2
 
 GRANT ALL ON tb_".$tables[$i]." TO $this->login WITH GRANT OPTION

mais quand je l'utilise avec un ibquery j'ai le message d'erreursuivant:

Code :

1
2
 
token unknown -line 1, char 16 ".$tables[$i]."

alors si quelqu'un a le même pb ou connait une methode pour eviter ce genre de
desagréments sa reponse est le bien venue

merci à tous

[qi130]

Code :

SQL.ADD('GRANT ADMINROLE TO MON_USER');

Ca ne me parait pas bon.....

Je coderai plutot :

Code :

SQL.ADD('GRANT ADMINROLE TO '+Edit1.Text);

avec Edit1.Text le même que dans

Code :

UserName := Edit1.Text;

Et puis, tu serais inspiré d'utiliser de lancer tes requètes dans un

Code :

1
2
Try.......
Except......

[Barbibulle]

Envoyé par devalender

BONJOUR A TOUS

j'ai en effet un pb avec les nouveaux utilisateurs que je crée en effet
j'ai une base de données avec 12 tables.
lorsque je crée un nouvelle user avec un mot de passe l'opération se
passe sans problème.
lorsque je tente d'accerder aux tables avec se nouveau user/password
j'ai le message suivant pour toutes les tables!

Code :

et ce message se repète pour toutes ces tables lorsque je tente
d'acceder aux données.

pour information voici comment je crée mon user/password

Code :

ensuite avec ce code je donne les droits suivants a mon_user

Code :

ADMINROLE est un role que j'ai crée avec IBconsole et je lui donné les
droits suivants:

Code :

Jusque là tout va bien, il ne vous reste plus qu'à connecter l'utilisateur en précisant le role qu'il va utiliser.
Dans les paramètres de connexion on peux préciser le role que l'on veux utiliser lors de la connection (sql_role_name=ADMINROLE).
Le 'GRANT ADMINROLE TO MON_USER' ne fait que donner le droit à MON_USER de pouvoir utiliser le role ADMINROLE.

Voilà l'autre solution (moins bonne à mon sens) est à chaque nouvel utilisateur redonner directement les droits. Mais celà veux dire que si on veux supprimer cet utilisateur, il faut lui supprimer tous les droits etc... bref c'est plus lourds.

[devalender]

je vous remercie pour tous
j'essai à nouveau de me mettre aun travail et je vous fait signe.

[Andry]

Bon, de ma part. Je suis aussi confronté à ce genre de pb.
Mais dans ma situation, j'ai deux roles différentes :
- une pour le superviseur
- une autre pour les simples utilisateurs
Le problème reside en faites dans le fait que on ne connait pas celui qui va se connecter, alors qu'on doit specifier le role à utiliser.

Actuellement, j'utilise la base de registre pour stocker le nom de celui qui va se connecter avec son role, mais cela implique que si quelqu'un d'autre va se connecter, il va pas reussir à avoir access au données, en plus si l'utilisateur reussi à changer le role, via la base de registre, ce sera la catastrophe.

Donc existe -t-il une solution moins lourde que celui de redonner directement le droit.

Merci

[Barbibulle]

En général l'interface superviseur d'une application n'est pas la même que celle de l'utilisateur courant et souvant c'est même une application différence (ce qui résoudrait votre probleme).

Sinon je vois trois autres solutions :
-Soit lors de l'écran d'identification vous demandez le type de connexion (Courant ou superviseur avec un radio bouton ou une case à cocher). Si une personne s'identifie avec son login et choisi superviseur alors qu'il n a pas les droits il va se faire sortir automatiquement.

-Soit dans l'écran d'identification en plus du nom et mot de passe vous obligez les superviseurs à appuyer sur CTRL+S par exemple et celà fait que l'identification se fait avec le role superviseur.

-Soit vous gérer une table des roles/personnes. La premiere connexion se fait toujour avec le role permettant de lire cette table pour récupérer le ou les roles associé à l'utilisateur. Puis fermer cette connexion pour en ouvrir une autre avec le bon role (éventuellement apres lui avoir proposé quel role il choisi dans le cas ou il en aurait plusieurs (si vous voulez gérer les personnes pouvant avoir plusieurs roles))

Donc en gros cela se resume en soit on demande à l'utilisateur comment il veut se connecter soit on se connecte en deux fois.

[Andry]

Salut,

J'aimerais eclaicir certaine choses à propos des roles.
Si par exemple j'ai deux roles : ADMIN et SIMPLE.
ensuite je permis à ANDRY d'utiliser le role ADMIN avec

Code :

1
2
 
GRANT ADMIN TO ANDRY;

Donc si je me connecte avec la base de donnée avec le role ADMIN ça va marcher.
Par contre si je me connecte avec la base de donnée avec le role SIMPLE, je vais me faire rejetté ?

Parce que si c'est le cas, la solution avec la case à cocher est faite pour moi.
Merci

[Barbibulle]

Bon pour eclaissir les choses :

-La création de user permet à celui-ci de se connecter à la base.
Donc que celui-ci ait des droits ou non la connnexion se fera. Si on veut que cette personne ne se connecte plus on lui supprime son compte.
Ca c'est la sécurité de 1er niveau qui autorise ou non la connexion à la base.


-Une fois la connexion effectuée, l'utilisateur peut avoir des droits d'accés.
Un droit d'accés c'est : droit de consulter, modifier, supprimer, créer, Exécuter ou Référencer.
Ces droits sont donnés soit en direct au USER soit à travers un ROLE.

Un USER peut faire parti de plusieurs ROLE mais il faut savoir que lors de la connexion on ne peux préciser qu'un seule role à la fois et donc si on veux utiliser pour ce même USER un autre role il faut soit se deconnecter et changer le role soit ouvrir une autre connexion avec l'autre role.

Si le USER a des droits attribués en directs et qu'il se connecte en utilisant un ROLE (dont il fait parti) les droits se combinent (Interbase va regarder au niveau du USER s'il a les droits sinon il regarde au niveau du ROLE qu'il utilise).

Si un USER se connecte en précisant un ROLE dont il ne fait pas parti, il n'y aura pas d'erreur de connexion, simplement le ROLE est ignoré et donc il n'aura que les droits qu'il lui aurait été attribué en direct.

Donc pour en revenir à votre cas :

Soit vous attribuez le role SIMPLE à tous vos USER (y compris les ADMINS) et attribués aux utilisateurs admins un second role ADMIN.

Puis vous demandez si la personne est ADMIN à ce moment vous utilisez le role ADMIN lors de la connexion (si cette personne n avait pas les droits admin elle ne pourra rien faire)
Si vous ne voulez pas demandez s'il est admin vous enregistrez dans une table le role à utiliser. Vous vous connectez avec le role SIMPLE, lisez votre table (ou les tables systems) si la personne a un role ADMIN vous vous deconnectez puis reconnectez en utilisant ce role (ainsi c'est transparent pour l'utilisateur)

Soit une solution que je ne vous ai pas exposé (car a mon sens plus lourde) vous attribuez les droits aussi bien au niveau des USERS et des ROLES. Vous vous connectez toujours avec le même ROLE.

par exemple :
Vous créez le role ADMIN, vous lui donnez les droits qui lui correspondent.
Et à chaque USER vous donnez les droits en direct sur les objets.
Vous attribué le ROLE ADMIN aux utilisateurs concernés.
Vous connectez toujours avec le ROLE ADMIN.
Ceux qui ne font pas parti du role ADMIN n'auront que les droits attribués en direct et ceux qui font parti du role ADMIN auront les droits attribués en direct et ceux attribués pour le role ADMIN.

exemple 2 : faire plutot l'inverse...(en général il y a moins d'admin ou de changement d'admin)
Créer un role SIMPLE et lui donner les droits correspondant.
Attribuer le role SIMPLE a tous les USERS.
Attribuez les droits spéciaux directement aux personnes administrateurs.
Vous connectez tout le monde avec le role SIMPLE.
Tous le monde a les mêmes droits (donnés par le role SIMPLE) et ceux qui sont administrateurs ont des droits supplémentaires mais qui leurs ont été attribués en direct.

Voilà et donc lors de l'identification plus besoin de demander autre chose que le nom et mot de passe.
J'espere que je n'ai pas été trop brouillon.

[Andry]

Envoyé par Barbibulle

Bon pour eclaissir les choses :

-La création de user permet à celui-ci de se connecter à la base.
Donc que celui-ci ait des droits ou non la connnexion se fera. Si on veut que cette personne ne se connecte plus on lui supprime son compte.
Ca c'est la sécurité de 1er niveau qui autorise ou non la connexion à la base.


-Une fois la connexion effectuée, l'utilisateur peut avoir des droits d'accés.
Un droit d'accés c'est : droit de consulter, modifier, supprimer, créer, Exécuter ou Référencer.
Ces droits sont donnés soit en direct au USER soit à travers un ROLE.

Un USER peut faire parti de plusieurs ROLE mais il faut savoir que lors de la connexion on ne peux préciser qu'un seule role à la fois et donc si on veux utiliser pour ce même USER un autre role il faut soit se deconnecter et changer le role soit ouvrir une autre connexion avec l'autre role.

Si le USER a des droits attribués en directs et qu'il se connecte en utilisant un ROLE (dont il fait parti) les droits se combinent (Interbase va regarder au niveau du USER s'il a les droits sinon il regarde au niveau du ROLE qu'il utilise).

Si un USER se connecte en précisant un ROLE dont il ne fait pas parti, il n'y aura pas d'erreur de connexion, simplement le ROLE est ignoré et donc il n'aura que les droits qu'il lui aurait été attribué en direct.

L'explication est limpide, rien à dire.

Envoyé par Barbibulle

Donc pour en revenir à votre cas :

Soit vous attribuez le role SIMPLE à tous vos USER (y compris les ADMINS) et attribués aux utilisateurs admins un second role ADMIN.

Puis vous demandez si la personne est ADMIN à ce moment vous utilisez le role ADMIN lors de la connexion (si cette personne n avait pas les droits admin elle ne pourra rien faire)
Si vous ne voulez pas demandez s'il est admin vous enregistrez dans une table le role à utiliser. Vous vous connectez avec le role SIMPLE, lisez votre table (ou les tables systems) si la personne a un role ADMIN vous vous deconnectez puis reconnectez en utilisant ce role (ainsi c'est transparent pour l'utilisateur)

Soit une solution que je ne vous ai pas exposé (car a mon sens plus lourde) vous attribuez les droits aussi bien au niveau des USERS et des ROLES. Vous vous connectez toujours avec le même ROLE.

par exemple :
Vous créez le role ADMIN, vous lui donnez les droits qui lui correspondent.
Et à chaque USER vous donnez les droits en direct sur les objets.
Vous attribué le ROLE ADMIN aux utilisateurs concernés.
Vous connectez toujours avec le ROLE ADMIN.
Ceux qui ne font pas parti du role ADMIN n'auront que les droits attribués en direct et ceux qui font parti du role ADMIN auront les droits attribués en direct et ceux attribués pour le role ADMIN.

exemple 2 : faire plutot l'inverse...(en général il y a moins d'admin ou de changement d'admin)
Créer un role SIMPLE et lui donner les droits correspondant.
Attribuer le role SIMPLE a tous les USERS.
Attribuez les droits spéciaux directement aux personnes administrateurs.
Vous connectez tout le monde avec le role SIMPLE.
Tous le monde a les mêmes droits (donnés par le role SIMPLE) et ceux qui sont administrateurs ont des droits supplémentaires mais qui leurs ont été attribués en direct.

Voilà et donc lors de l'identification plus besoin de demander autre chose que le nom et mot de passe.
J'espere que je n'ai pas été trop brouillon.

La deuxième idée celui du tout le monde en role SIMPLE et droit directe pour les admins me convient parfaitement, surtout que les dans les admins peuvent juste en plus des SIMPLES faire une update et delete sur une table.

Juste une dernière question : dois je donc effacer les permissions attribué à chaque utilisateur avant de l'effacer ?

Merci encore Barbibulle.

[Barbibulle]

Envoyé par Andry

Juste une dernière question : dois je donc effacer les permissions attribué à chaque utilisateur avant de l'effacer ?

Si vous supprimez un utilisateur il ne peux plus se connecter et donc de ce fait il n'a plus de droit...

Par contre si vous recréez le même utilisateur, (même identifiant) il va retrouvez ses droits dans votre base (appartenance aux roles et droits directs).
Si vous voulez évitez ça ou faire le menage correctement il vous faut donc lui retirer ses droits.
Donc pour l'utilisateur simple il faut l'enlever du role SIMPLE.
et pour les admin leur enlever les droits particuliers et le role SIMPLE.


Bon en me relisant, je me suis apperçu que j'ai oublié une chose importante.
PUBLIC qui pour résumer sert à définir les droits mini des utilisateurs.
Donc pour vous donnez une autre (et dernière) solution il faut que vous donniez les droits (equivallent à ceux que vous arriez mis au role SIMPLE) à PUBLIC.
Puis creez un seul role ADMIN avec les droits adequats.
Enfin attribuez le role ADMIN aux personnes concernés.
N'attribuez aucun droit en direct.

Connectez tout le monde en utilisant le role ADMIN (seul ceux qui sont ADMIN pourront de toute façon avoir les droits).

Que se passe t'il ? Et bien vos utilisateurs 'normaux' n'ont aucuns droits en direct et ne font pas parti de role non plus mais beneficient des droits minimum (défini avec PUBLIC).
Les utilisateurs administrateurs eux auront les droits PUBLIC plus les droits attribués au role ADMIN (car la connexion se fait toujours avec le ROLE ADMIN).

C'est donc une autre solution que je viens de vous décrire. L'avantage qu'elle apporte c'est que lorsqu'on crée ou supprime un utilisateur normal il est inutile de lui donner des droits ou un role dans la base. L'inconvénient (puisqu'il faut bien qu'il y en ait) c'est qu'il aurra donc les droits attribués à PUBLIC dès lors qu'on a créée cet utilisateur.
Pour effacer un admin on va d'abord lui retirer le role ADMIN puis on pourra le supprimer.

[Andry]

La dernière idée de barbibulle marche bien.
1 - Juste un hic pour la suppression comment retirer le role admin sur un utilisateur. j'ai beau chercher la syntaxe exacte de REVOKE mais je vois pas comment faire.
2 - Y a t-il un moyen de donner à un autre utilisateur autre que SYSDBA le droit d'ajouter/supprimer/Editer un compte.

Merci

[Barbibulle]

Envoyé par Andry

La dernière idée de barbibulle marche bien.
1 - Juste un hic pour la suppression comment retirer le role admin sur un utilisateur. j'ai beau chercher la syntaxe exacte de REVOKE mais je vois pas comment faire.

Supposons que j'ai créé un role qui s'appel ROLEADMIN :

Code :

REVOKE ROLEADMIN FROM USER Andry;

ou

Code :

REVOKE ROLEADMIN FROM Andry;

Car USER est optionnel,
permet d'enlever ANDRY du role ROLEADMIN.

Envoyé par Andry

2 - Y a t-il un moyen de donner à un autre utilisateur autre que SYSDBA le droit d'ajouter/supprimer/Editer un compte.

Il ne me semble pas (j ai jamais essayé).
Par contre il faut savoir que les objets d'une base ont un "Owner" (que l'on pourait traduire pas pocesseur ou plutot créateur). Le user qui est référencé comme étant le "Owner" a tous les droits sur cet objet.
Par défaut c'est SYSDBA car en général on créé la base et tout le reste avec le compte SYSDBA. Mais on peux très bien (après avoir créé un user ANDRY par exemple) créer toute la base en utilisant ANDRY comme USER. Ainsi ANDRY aurait les même droit sur cette base que SYSDBA (celà vaut aussi pour exécuter un backup / ou gstat ou gfix ou pour restaurer sur la base existante qui sont des opérations réservées normalement au SYSDBA)

[Andry]

[quote="Barbibulle"]
Supposons que j'ai créé un role qui s'appel ROLEADMIN :

Code :

REVOKE ROLEADMIN FROM USER Andry;

ou

Code :

REVOKE ROLEADMIN FROM Andry;

Car USER est optionnel,
permet d'enlever ANDRY du role ROLEADMIN.

Envoyé par Andry

Super en faites il fallait mettre FROM mais pas TO (que suis bête

Envoyé par Barbibulle

Il ne me semble pas (j ai jamais essayé).
Par contre il faut savoir que les objets d'une base ont un "Owner" (que l'on pourait traduire pas pocesseur ou plutot créateur). Le user qui est référencé comme étant le "Owner" a tous les droits sur cet objet.
Par défaut c'est SYSDBA car en général on créé la base et tout le reste avec le compte SYSDBA. Mais on peux très bien (après avoir créé un user ANDRY par exemple) créer toute la base en utilisant ANDRY comme USER. Ainsi ANDRY aurait les même droit sur cette base que SYSDBA (celà vaut aussi pour exécuter un backup / ou gstat ou gfix ou pour restaurer sur la base existante qui sont des opérations réservées normalement au SYSDBA)

Le problème est que sous Delphi, j'ai une erreur lorsque je n'utilise pas SYSDBA

have no permission to write/insert to table USERS.

Je pense que la Table USERS en question ici est l'une des tables systemes d'Interbase.
Bon, je vais tenter de creer ma base avec une owner autre que SYSDBA pour voir si ça marche.
En faites j'aimerais pas qu'on utilise SYSDBA chez le client pour raison de securité.

Merci encore