Discussion :

[candesign]

Bonjour à tous,

Je suis entrain de développez une application .Net qui devra se connecter à Oracle.

En matière d'architecture, je souhaite que la gestion des utilisateurs soit intégrée dans mon application. Donc la création, la suppression, les droits d'accès... devront se faire à partir de l'interface de mon application sans que l'utilisateur n'ait à toucher à oracle.

Cependant j'ai eu le problème suivant :

Oracle ajoute lors de la création de chaque BDD une trentaine d'utilisateurs auxquels devront s'ajouter ceux créés par mon application. Cependant lors de l'administration de mon application je voudrai que seuls, les utilisateurs créés à partir de mon application soit visibles.

Donc il me fallait un moyen pour les identifier séparément.

J'ai pensé en premier lieu à rajouter un champ dans la table Users de Oracle pour spécifier s'il s'agit d'un utilisateur créé par Oracle ou un utilisateur créé par l'administrateur de mon application. Mais d'après le thread Link c'est totalement déconseillé et peut être pas possible...

Donc j'ai pensé à créer une table Séparée dans laquelle je stockerai (aussi) les informations relatives aux utilisateurs créés par mon application.

En faisant ceci, j'ai été confronté à un autre problème:

Etant donné que les 2 tables ne font pas partie du même schéma. La tables Users fait partie du schéma System et l'autre créée par moi même fait partie d'un autre schéma, j'ai eu du mal à créer un lien de clé étrangère entre les deux. J'ai essayé des requêtes du genre :

Code :

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

Alter table DBArchitect.MyUsers add Constraint LinkToSytemUsersTable foreign key(ID) references sys.dba_users(user_ID);

mais sans succès. Je reçois l'erreur Ora 942 (Table ou vue inexistante...)

Je peux faire le lien entre les 2 tables sans clé étrangère mais je cherche plutôt une solution robuste assurant l'intégrité référentielle.

Quelqu'un aurait une idée dans ce sens, s'il vous plait ?

Je vous remercie d'avance !

[Pomalaix]

... Je reçois l'erreur Ora 942 (Table ou vue inexistante...)

A priori, c'est juste que votre utilisateur n'a pas les droits d'accès à la vue DBA_USERS.

Avec Oracle 12c, vous disposez de la colonne ORACLE_MAINTAINED qui répond pile-poil à votre besoin :

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
37
38
39
40
41
42
SQL> show release
release 1201000100
 
SQL> select username from dba_users where oracle_maintained='Y' order by 1;
 
USERNAME
----------------------------------------------------------------------------
ANONYMOUS
APEX_PUBLIC_USER
APEX_040200
APPQOSSYS
AUDSYS
CTXSYS
DBSNMP
DIP
DVF
DVSYS
FLOWS_FILES
GSMADMIN_INTERNAL
GSMCATUSER
GSMUSER
LBACSYS
MDDATA
MDSYS
OJVMSYS
OLAPSYS
ORACLE_OCM
ORDDATA
ORDPLUGINS
ORDSYS
OUTLN
SI_INFORMTN_SCHEMA
SPATIAL_CSW_ADMIN_USR
SPATIAL_WFS_ADMIN_USR
SYS
SYSBACKUP
SYSDG
SYSKM
SYSTEM
WMSYS
XDB
XS$NULL

[Baldrick]

Bonjour,

Code :

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

Alter table DBArchitect.MyUsers add Constraint LinkToSytemUsersTable foreign key(ID) references sys.dba_users(user_ID);

mais sans succès. Je reçois l'erreur Ora 942 (Table ou vue inexistante...)

Comme l'a écrit Pomalaix, il faut que DBArchitect ait le privilège REFERENCES sur la vue dba_users pour éviter cette erreur. Mais ce ne sera pas suffisant pour créer cette contrainte. J'ai essayé et suis tombé sur un autre os beaucoup plus coriace : l'absence de contrainte unique / primary key sur la colonne que l'on veut référencer... Je n'en ai pas cru mes yeux et suis allé vérifier dans la table sys.user$ et effectivement il n'y a pas de contrainte unique sur user# (il y a deux index uniques sur la table, mais pas de contraintes associées, pour une raison qui m'échappe), et donc la création d'une clé étrangère vers cette table est impossible, sauf à modifier sa structure,ce qui est fortement déconseillé, cela va sans dire.


Pour en revenir au problème... Si vous êtes en 12c, Pomalaix a fourni la solution.

Si vous n'êtes pas en 12c... On peut se baser sur leur date de création, mais il faut prendre en compte le fait que l'utilisateur XS$NULL semble être recréé automatiquement de temps à autre... Personnellement, je pense que je recenserais les utilisateurs créés par le système et créerais une vue qui interroge dba_users en les ignorant. C'est simple et sûr.

Cependant, votre idée d'enregistrer les utilisateurs intégrés à votre application dans une table à part n'est pas mauvaise (surtout s'il vous faut leur associer des informations spécifiques). Mais comme je l'ai exposé plus haut, sauf erreur de ma part, la création de la contrainte references est impossible, ce qui oblige à trouver un autre moyen de maintenir l'intégrité. Peut-être qu'un trigger qui répercuterait les insert/delete de la table sys.users sur votre table ferait l'affaire...

[Pomalaix]

Bien vu pour l'exigence d'une clé primaire ou unique !!

... Peut-être qu'un trigger qui répercuterait les insert/delete de la table sys.users sur votre table ferait l'affaire...

Pour votre dernière proposition, c'est une autre restriction qui s'en mêle, et vous donnera ceci :

Code :

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

ORA-04089: impossible créer déclencheurs sur objets appartenant à SYS

[candesign]

Cependant, votre idée d'enregistrer les utilisateurs intégrés à votre application dans une table à part n'est pas mauvaise (surtout s'il vous faut leur associer des informations spécifiques).

C'est exactement ça mon problème ! J'ai justement besoin d'avoir d'autres informations autre que le Login et le mot-de-passe.

la création de la contrainte references est impossible, ce qui oblige à trouver un autre moyen de maintenir l'intégrité. Peut-être qu'un trigger qui répercuterait les insert/delete de la table sys.users sur votre table ferait l'affaire

Tant pis ! Je pense que je vais partir sur ça alors et créer des déclencheurs !

Merci à vous tous !

[pachot]

Bonjour,
Le plus simple serait peut-être de créer des profils spécifiques pour les users de l'application (ce qui n'est pas une mauvaise idée de toute façon). Et l'info est présente dans ALL_USERS.
Cordialement,
Franck.

[candesign]

Bonjour,
Le plus simple serait peut-être de créer des profils spécifiques pour les users de l'application (ce qui n'est pas une mauvaise idée de toute façon). Et l'info est présente dans ALL_USERS.
Cordialement,
Franck.

Je compte faire ça aussi Franck mais y a-t-il une différence un profil et un rôle ? Apparemment c'est pas la même chose.

[Baldrick]

Ce n'est effectivement pas du tout la même chose : un rôle est une collection de privilèges qui permet de simplifier l'administration des droits. Un profil est un ensemble de règles qui couvrent la gestion des mots de passe (durée de validité, complexité, nombre d'erreurs de saisie avant verrouillage du compte, etc.) ou l'utilisation des ressources systèmes (nombre de sessions qu'il peut ouvrir, durée d'inactivité avant déconnexion, temps de CPU utilisable, etc.).

On notera aussi qu'un utilisateur peut disposer de plusieurs ou même d'aucun, tandis qu'il a forcément un et un seul profil.


@Pomalaix : merci pour avoir signalé l'ORA-04089. Je la connaissais pas, celle-là.