Comment identifier les utilisateurs créés "manuellement" de ceux créés automatiquement par Oracle ?

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:

---

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 :) !

Citation:

---

Envoyé par candesign

... 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:

---

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

---

Bonjour,

Citation:

---

Envoyé par candesign

Code:

---

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...

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

Citation:

---

Envoyé par Baldrick

... 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:

---

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

---

Citation:

---

Envoyé par Baldrick

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.

Citation:

---

Envoyé par Baldrick

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 :) !

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.

Citation:

---

Envoyé par 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.

---

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.

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à.