Discussion :

[pelo68]

Bonjour,

J'ai une base de données multimedia à faire et on nous demande de gérer les utilisateurs et leur droit.....
Ainsi un utilisateur X peut voir toutes les images, insérer des images mais supprimer uniquement les images appartenant a X....
Et bien sur l'utilisateur ZZ qui lui peut tout faire (proprietaire de la base)


J'ai commencé à chercher du coté de GRANT .... TO .... ON ...
Pour la distinction entre X et ZZ je pense qu'il faut utiliser cela mais par contre comment faire si on a plusieurs utilisateurs X pour empecher qu'ils supprimment les photos ne leur appartenant pas ?

Faire un champ en plus dans la table ?? Genre user varchar2 ???

Merci pour votre aide

[nuke_y]

Tout dépend de l'architecture.

Je serais tenté de dire que si une table contient la liste des images avec leur propriétaire, et que pour un utilisateur Oracle on a de manière bijective un utilisateur Applicatif, c'est à l'application de gérer le fait que l'utilisateur Applicatif X1 n'a pas le droit de demander la suppression en base de données appartenant à l'utilisateur Applicatif X2, alors que l'utilisateur ZZ a tous les droits.

[sygale]

Les droits SELECT, INSERT, UPDATE, DELETE sont au niveau TABLE, pas au niveau d'une ligne.

Si toutes les images sont dans une même table, je suis d'accord avec nuke_y, c'est à l'application de faire ca, c'est une règle de gestion.

Si toutes les images par utilisateur = une table le pb est résolu. mais cela serait étonnant comme architecture

Sinon tu peux mettre un trigger on delete exemple :

Code :

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

1
2
3
4
5
6
7
8
9
create or replace trigger tg_be_up_image before delete
on image
referencing old as old for each row
begin
 if :old.owner_image != user then
    raise_application_error(-20001,'Vous ne pouvez pas supprimer des images ne vous appartenant pas ...')
 end if;
end;
/

[laurentschneider]

à qui appartient la table?

si j'ai bien compris la question tu as une table T qui a une colonne image

Code :

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

1
2
3
4
5
6
 
SQL> select * from u.t;
IMAGE
----------------------------------------
terre.jpg
ciel.jpg

D'abord un rajoute une colonne USERNAME

Code :

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

1
2
3
4
5
6
7
 
SQL> alter table u.t add (USERNAME varchar2(30) default USER);
SQL> select * from u.t;
IMAGE                                    USERNAME
---------------------------------------- -----------
terre.jpg                                SYS
ciel.jpg                                 SYS

ensuite tu crées des vues. Une pour insérer, une pour supprimer

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SQL> create or replace view u.vue_pour_delete as 
2  select image from u.t where username=user;
View created.
SQL> create or replace view u.vue_pour_insert as select image from u.t;
View created.
SQL> grant select on u.t to public;
Grant succeeded.
SQL> grant insert on u.vue_pour_insert to public;
Grant succeeded.
SQL> grant delete on u.vue_pour_delete to public;
Grant succeeded.

essayons !

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
SQL> connect scott
Enter password:
Connected.
SQL> select * from u.t;
IMAGE                                    USERNAME
---------------------------------------- ----------
terre.jpg                                SYS
ciel.jpg                                 SYS
SQL> delete u.t;
delete u.t
         *
ERROR at line 1:
ORA-01031: insufficient privileges
 
SQL> insert into u.t values ('eau.jpg','dieu');
insert into u.t values ('eau.jpg','dieu')
              *
ERROR at line 1:
ORA-01031: insufficient privileges
 
SQL> insert into u.vue_pour_insert values ('feu.jpg');
1 row created.
SQL> select * from u.t;
IMAGE                                    USERNAME
---------------------------------------- ------------------------------
feu.jpg                                  SCOTT
terre.jpg                                SYS
ciel.jpg                                 SYS
SQL> delete u.vue_pour_delete;
1 row deleted.
SQL> select * from u.t;
IMAGE                                    USERNAME
---------------------------------------- ------------------------------
terre.jpg                                SYS
ciel.jpg                                 SYS

OK?

[sygale]

Excellent !

[nuke_y]

Certes c'est excellent mais pour moi cela déplace les régles de gestion de l'applicatif vers la base de données, et c'est à proscrire.

Car tu pars du principe qu'un utilisateur applicatif = un utilisateur BDD et tout changement dans les règles de gestion ou attribution/suppression de droit devra se faire sur la base et pas dans l'application.

[pelo68]

Je suis partit 20min je reviens et 4 réponses !

laurentschneider >
Merci c'est exactement ce que je voulais faire....

J'aurais encore une autre question.... Enfin 2 pour etre exacte ( )

La structure de ma table est plus ou moins la suivante :

Code :

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

1
2
3
4
5
6
7
8
 
CREATE TABLE image (
  id NUMBER(8,0) NOT NULL,
  nom VARCHAR2(50) NOT NULL,
  date_modif DATE NOT NULL,
  description VARCHAR2(80) NOT NULL,
  file BLOB,
  PRIMARY KEY(id));

Avec une sequence pour id....

J'aurais aimé rajouter un champ categorie (par exemple : Vacances, Nouvel an, etc)
Sachant que une categorie comporte une ou plusieurs images je pense qu'il serait mieux de faire une seconde table du genre

Code :

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

1
2
3
4
5
 
CREATE TABLE categorie (
  id_cat NUMBER(8,0) NOT NULL,
  nom_cat VARCHAR2(80) NOT NULL,
  PRIMARY KEY(id_cat));

De nouveau avec une sequence pour id_cat et rajouter à ce moment là un champ id_cat dans la table image....

Est ce que l'on peut assigner une valeur par default a ce champ sachant qu'il fait reference a la seconde table ?
Je suppose que l'on peut faire quelque chose comme ceci :
id_cat NUMBER(8,0) DEFAULT 1 NOT NULL

Avec dans la table categorie 1 qui correspond a 'default' par exemple

Et ma 2eme question est la meme mais pour les utilisateurs.....
Etant donné qu'il y aura comme dans l'exemple de laurentschneider plusieurs fois le meme nom est il plus intelligent de le stocker dans une table a part ?

[sygale]

Car tu pars du principe qu'un utilisateur applicatif = un utilisateur BDD et tout changement dans les règles de gestion ou attribution/suppression de droit devra se faire sur la base et pas dans l'application.

Effectivement sauf que là tu es libre car si tu ajoutes un user il fonctionnera de suite, si tu en supprimes un aussi (ses images seront perdues certes)

Nous avons un user applicatif = un user BDD avec un role spécifique.
Vous avez 1 user applicatif ? comment faite vous pour les reconnaître ?

Sinon, tu peux faire ca aussi avec un user applicatif, il suffit de l'avoir dans la base et hop cela fait

Code :

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

1
2
create or replace view u.vue_pour_delete as 
select image from u.t where username=f_ret_user_applicatif;

[laurentschneider]

Certes c'est excellent mais pour moi cela déplace les régles de gestion de l'applicatif vers la base de données, et c'est à proscrire.

il est beaucoup plus efficace d'avoir une contrainte dans la base de données que dans l'application. Ce qui est à proscrire, c'est les développeurs qui n'emploient pas pleinement les fonctionalités de la base de donnée et gère systèmatiquement les contraintes avec du code

pelo68: ta question 1, il me semble que tu y as répondu toi même.

Pour ta question 2, le nom de l'utilisateur est déjà dans DBA_USERS, et il est à mon sens superflus de créer une table à part.

[LeoAnderson]

Certes c'est excellent mais pour moi cela déplace les régles de gestion de l'applicatif vers la base de données, et c'est à proscrire.

Car tu pars du principe qu'un utilisateur applicatif = un utilisateur BDD et tout changement dans les règles de gestion ou attribution/suppression de droit devra se faire sur la base et pas dans l'application.

Oui, et c'est ce qu'il y a de plus sûr si on veut cloisonner les données sans se prendre la tête à développer une appli. qui va filtrer alors qu'un coup de SQL*Plus et hop, on a accès à tout !

Le plus efficace est donc, si possible d'implémenter les VPD qui permettent des restrictions au niveau ligne, ce que ne permettent pas les privilèges ! ;-)

[nuke_y]

il est beaucoup plus efficace d'avoir une contrainte dans la base de données que dans l'application. Ce qui est à proscrire, c'est les développeurs qui n'emploient pas pleinement les fonctionalités de la base de donnée et gère systèmatiquement les contraintes avec du code

c'est ce qu'il y a de plus sûr si on veut cloisonner les données sans se prendre la tête à développer une appli. qui va filtrer alors qu'un coup de SQL*Plus et hop, on a accès à tout !

Je suis d'accord avec vous d'un point de vue facilité et rapidité de développement, cependant d'un point de vue maintenabilité / évolution / "propreté" c'est à proscrire.

Assez souvent je suis obligé d'utiliser des spécificités des BDD pour résoudre des problèmes que mes outils (ETL, outils de restitution comme Business Object) ne sont pas capables de résoudre, en insérant des Hint, en utilisant des vues, etc. Mais je remarque que ça pose énormément de problèmes par la suite d'un point de vue évolution de l'application, transfert de compétences, voir portabilité de l'application.

Ce n'est pas la question ici donc je répète ce que j'ai dit, je trouve la solution de laurentschneider bien faite MAIS pour MOI c'est à proscrire, pour tout un tas de raisons, la première étant l'idée qu'un user applicatif = un user BDD et le postulat qu'on a parfaitement la main sur la BDD (ajout/suppression de droits et d'USER).

[pelo68]

Merci pour toute vos reponses....

Apres l'avoir brievement testé je pense que je vais utiliser la solution de laurentschneider....
Je mettrais une authentification au niveau de l'application java de maniere à ce qu'il faut d'abord s'etre loggué avant de pouvoir utiliser l'application....

Car le projet est clairement orienté base de données donc je pense qu'il vaut mieux utiliser les vues que d'essayer de gérer cela au niveau de l'application....

Encore une fois merci !