Discussion :

[JustMe]

je cherche des exmples d'applications qui utilisent les rôles permis par FireBird car je n'arrive pas à assimiler vraiment comment on fait. Faut-il réécrire toutes mes requêtes pour chacun des rôles que je créé? ou quoi? je ne sais pas car si un utilisateur avec un role qui ne lui permet par de séléctionner tel ou tel champs ou d'executer telle ou telle procédure génère une exception.
Juste une piste m'enchantera. Merci.

[qi130]

Il faut voir le role comme un profil d'utilisateur...

Imaginons un soft de gestion de PME. Il y a la paie, la compta, les factures, etc...

Prenons le cas d'un stagiaire. On ne veut pas le laisser tout casser; hein ?

On crée un role "stagiaire" (create role)
Puis sur les tables et procédures : grant SELECT on [tables/procs] to stagiaire, afin de ne lui permettre que la consultation.

Et enfin grant stagiaire to [le user attribué au stagiaire].

Le mois d'après, un autre stagiaire arrive: il y a juste à lui granter le rôle

[JustMe]

excuser mon ignorance mais jusque là c'est bon, mais au niveau application cliente on fait quoi pour la généraliser afin de l'adapter au différent roles présents sur la base de données.

[qi130]

Eventuellement rien si l'appli intercepte correctement l'erreur due au manque de privilèges...

Il faut aussi penser que le "stagiaire" peut installer un outil genre IBExpert pour visiter la base.

[_skip]

excuser mon ignorance mais jusque là c'est bon, mais au niveau application cliente on fait quoi pour la généraliser afin de l'adapter au différent roles présents sur la base de données.

Si vous travaillez en .Net ou en Java, la requête qui n'a pas fonctionné à cause des rôles retournera une exception que vous devrez gérer au sein de votre couche métier. Pour la différencier des autres erreurs, il faudra utiliser le code d'erreur qu'elle contiendra.

Sinon, il est aussi possible de gérer des rôles au niveau de l'application en autorisant ou non certaines actions, c'est parfois plus souple que de le faire directement au niveau base. Il faut vraiment réfléchir à ce qui est le plus pertinent pour vous, en tenant compte de votre application et du cadre de l'entreprise.

[JustMe]

merci pour vos réponses mais je ne saisi toujours pas comment on peut concevoir une application qui s'adapte à tous les roles présents dans une base de données.
Juste pour savoir : Est ce que quelqu'un l'a déja fait?

[makowski]

on ne conçoit pas une application qui s'adapte à des roles
quand on se connectec à une base, on peut choisir un role dans la chaine de connexion, et donc on travaille avec les droits qui y sont associés

[JustMe]

c'est ce que je cherche à comprendre

on travaille avec les droits qui y sont associés

donc on n'a pas le droit de changer quoi que ce soit dans un role si une application a été déjà conçue?
J'ai besoin d'une façon de procéder pour que mon application soit fléxible dans ce genre de cas. Un exemple serait pour moi le paradis.

[makowski]

ce n'est pas compliqué
un utilisateur ou un role a des droits (SELECT INSERT UPDATE EXECUTE) ou pas selon les objets, donc le moteur Firebird le laisse ou non utiliser ces commandes sur tel ou tel objet, c'est tout.
si tu fais un select sur une table sur laquelle tu n'as pas le droit, tu recevra une erreur et basta

[_skip]

Si il pouvait détailler ce qu'il essaie de faire et le langage de dév utilisé... Je pourrai préciser ma réponse.