Nombre de Vues / base

Version imprimable

07/03/2023, 13h56
laurent1133

Nombre de Vues / base

Est ce une bonne stratégie d'utiliser 200 vues ou plus dans une base ?
07/03/2023, 15h00
Artemus24

Salut Laurent1133.

D'utiliser des view, oui, c'est une bonne stratégie.
Sur le nombre de view, il est difficile de répondre si l'on ignore de quoi il s'agit.
Sont-elles très différentes les unes des autres ?
Ou bien, elles diffèrent sur un seul critère ?

Cordialement.
Artemus24.
@+
07/03/2023, 16h37
escartefigue

Afin de rendre les traitements indépendants des données, on devrait toujours passer par des vues, ne jamais lire directement les tables dans les traitements.
Après leur nombre dépend du nombre de tables et du besoin.
08/03/2023, 06h55
laurent1133

Vues

Ok, alors les vues se ressemblent. J'ai voulu faire une base utilisateurs partagée entre plusieurs groupes. ( et J'ai une table avec le privilège Delete)...
08/03/2023, 10h36
Artemus24

Salut Laurent1133.

J'ai du mal à te suivre dans tes explications.

Citation:

Envoyé par Laurent1133

Ok, alors les vues se ressemblent.

Si elles sont presques identiques, mais différent sur un seul critère, il faut voir si l'on peut pas mettre ce critère en paramètre dans la view.

Citation:

Envoyé par Laurent1133

J'ai voulu faire une base utilisateurs partagée entre plusieurs groupes.

Il faut faire la distinction entre les privilèges d'accès aux tables que tu renseignes par un grant pour chaque utilisateur.
Et la façon d'accéder à cette table, enfin je devrais plutôt dire aux données.

Comme le dit Escartefigue, personne ne doit avoir accès aux tables diectement.
C'est une mauvaise façon de travailler car les accès doivent être gérés par les privilèges.
Et pour distinguer tel utilisateur qui est autorisé d'un autre qui ne l'est pas, cela doit se faire dans une View.

Prenons le cas où tu as deux utilisateurs.
L'un est autorisé à lire une colonne tandis que l'autre n'a pas l'autorisation.
Mais inversement, ils sont tous les deux autorisés à lire les autres colonnes.
Dans ce cas, tu dois créer deux View où dans l'une tu mets la colonne, et dans l'autre View, elle n'y figure pas.
Au niveau application, tu devras identifier l'utilisateur et fournir la bonne View.

Que ce passe-t-il si tu ne fais pas cette distinction ?
L'utilisateur qui n'est pas autorisé à lire la colonne en question, ne pourra pas lire les autres colonnes car sa requête va se terminer en erreur.

C'est très bien, quand il s'agit d'accès aux tables et aux colonnes.
Mais quand est-il si l'accès se fait sur certaines lignes mais pas sur d'autres ?
Dans ce cas, il faut étiqueter les lignes par une autre colonne qui va donner l'autorisation où pas.

Nommons cette colonne "critere".
Tu vas devoir gérer une table qui va contenir :
--> la fameuse colonne "critere"
--> l'identifiant de l'utilisateur
--> éventuellement le nom de la table où celui-ci désire accéder

et en résultat, tu sauras s'il est autorisé à l'accès ou pas.
C'est dans une View particulière que tu vas faire cette recherche d'autorisation.
Cette View, tu pourras l'appeler partout dans toutes tes autres Views quand tu as besoin de savoir qui est autorisé ou pas à accéder aux lignes.
En appliquant ce principe, tu risques d'avoir deux Views au maximum par table, mais pas plus.

Cordialement.
Artemus24.
@+
09/03/2023, 12h50
laurent1133

1 pièce(s) jointe(s)

Vues

Merci pour ta réponse Artemus24, je vais essayé de l'appliqué. (Voici mon schéma actuel), tant que l'on utilise l'application rien de grave, en mode console pff !
Pièce jointe 635472
10/03/2023, 09h26
Artemus24

Salut Laurent1133.

Si tu veux de l'aide, il faudrait être un peu plus précis sur ce que tu cherches à faire exactement et que tu n'y arrives pas.
Un exemple sera un peu plus parlant, surtout s'il y a un jeu d'essai.
Tu précises pourquoi cela ne fonctionne pas et si c'est pas trop tordu à faire, je peux te proposer une solution.

Cordialement.
Artemus24.
@+
12/03/2023, 16h43
laurent1133

Vues

Bjr Artemus24, en fait tu m'as donné la solution, mettre un paramètre dans une vues. Mais je veux bien un coup de main, je ne sais pas activer un paramètre MySql, ni le transmettre depuis PHP.

Salut Laurent1133.

Voici un simple exemple, où un utilisateur appartient à un seul groupe.

J'utilise trois utilisateurs, "userone", "usertwo" et "userthree" et une database de nom "base".
J'attribue à chacun de ces utilisateurs, un rôle "roleone" et "roletwo" qui va contenir les autorisations sur les vues.
Il y a trois vues. "Vue_un" est lié à "roleone", "vue_deux" à "roletwo" et "vue_trois" aux deux rôles.
"Vue_trois" sert uniquement au vidage de la table "article" et n'a pas vocation à être utilisée.
C'est juste pour vérifier que tout se passe correctement dans la table "article".

Ce qui est important, ce sont les rôles et leur attribution aux utilisateurs.
Tu peux considérer qu'un rôle, c'est un groupe de travail.
Un utilisateur peut recevoir plusieurs rôles, donc appartenir à plusieurs groupes, mais je n'ai pas traité ce cas.

Le teste est basé sur les différences d'accès des deux vues.
"Userone" peut lire la colonne "val" et pas la colonne "num". Inversement pour l'utilisateur "usertwo".

Le principe est de ne pas accéder aux tables directement, mais en passant par des view.
les view sont forts simples car elles ne font références aux colonnes où l'utilisateur est autorisé à y accéder.
La restriction concerne les lignes par l'intermédiaire de la colonne "groupe".
Un utilisateur appartenant à un groupe peut accéder aux lignes de son groupe, même s'il n'est pas le créateur de cette ligne.

Comment nommer les view ? Tu peux associer dans le nom de la view, le rôle d'appartenance. Je ne l'ai pas fait.

Il y a un bug dans Mysql que je n'ai pas pu résoudre.
Normalement, je peux récupérer le rôle attribué pour l'utilisateur. Il s'agit de la fonction CURRENT_ROLE().
Mais je ne sais pas pourquoi, elle ne fonctionne pas dan sun déclencheur où elle retourne tout le temps "NONE".
Pour ce faire, j'ai créé une fonction de nom "ROLEHOST()" qui est l'exact valeur du rôle de l'utilisateur.

Création de la base de données et des views :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
--------------
START TRANSACTION
--------------
 
--------------
set session collation_connection = latin1_general_ci
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE IF NOT EXISTS `base`
        DEFAULT CHARACTER SET `latin1`
        DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP FUNCTION IF EXISTS `rolehost`
--------------
 
--------------
CREATE FUNCTION `rolehost`() RETURNS varchar(255)
  DETERMINISTIC
  LANGUAGE SQL
BEGIN
  RETURN (select group_concat(role_name,'@',role_host) from information_schema.APPLICABLE_ROLES);
END
--------------
 
--------------
DROP TABLE IF EXISTS `article`
--------------
 
--------------
CREATE TABLE `article`
( `id`       integer unsigned NOT NULL auto_increment primary key,
  `lib`      varchar(255)     NOT NULL,
  `val`      NUMERIC(15,2)        NULL DEFAULT 0,
  `num`      NUMERIC(15,2)    NOT NULL DEFAULT 0,
  `created`  datetime         NOT NULL DEFAULT current_timestamp,
  `updated`  datetime         NOT NULL DEFAULT current_timestamp ON UPDATE CURRENT_TIMESTAMP,
  `group`    varchar(255)     NOT NULL,
  `creator`  varchar(255)     NOT NULL
  ) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
DROP TRIGGER IF EXISTS `creator`
--------------
 
--------------
CREATE TRIGGER `creator`
BEFORE INSERT ON `article`
FOR EACH ROW
BEGIN
  set new.`creator` = USER();
  set new.`group`   = ROLEHOST();
END
--------------
 
--------------
DROP VIEW IF EXISTS `vue_un`
--------------
 
--------------
CREATE VIEW `vue_un` AS
    SELECT  `id`,
            `lib`,
            `val`
      FROM  `article`
     where `group` in (ROLEHOST())
--------------
 
--------------
DROP VIEW IF EXISTS `vue_deux`
--------------
 
--------------
CREATE VIEW `vue_deux` AS
    SELECT  `id`,
            `lib`,
            `num`
      FROM  `article`
     where `group` in (ROLEHOST())
--------------
 
--------------
DROP VIEW IF EXISTS `vue_trois`
--------------
 
--------------
CREATE VIEW `vue_trois` AS
  SELECT  `id`,
          `lib`,
          `val`,
          `num`,
          `created`,
          `updated`,
          `creator`,
          `group`
    FROM  `article`
--------------
 
--------------
COMMIT
--------------
 
Appuyez sur une touche pour continuer...

Voici les privilèges :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
--------------
START TRANSACTION
--------------
 
--------------
SET PERSIST mandatory_roles = ''
--------------
 
--------------
commit
--------------
 
--------------
drop   role if exists                                                                          'roleone'@'localhost'
--------------
 
--------------
create role                                                                                    'roleone'@'localhost'
--------------
 
--------------
grant select(id,lib,val),insert(id,lib,val),update(id,lib,val),delete on `base`.`vue_un`    to 'roleone'@'localhost'
--------------
 
--------------
grant select                                                          on `base`.`vue_trois` to 'roleone'@'localhost'
--------------
 
--------------
drop   role if exists                                                                          'roletwo'@'localhost'
--------------
 
--------------
create role                                                                                    'roletwo'@'localhost'
--------------
 
--------------
grant select(id,lib,num),insert(id,lib,num),update(id,lib,num)        on `base`.`vue_deux`  to 'roletwo'@'localhost'
--------------
 
--------------
grant select                                                          on `base`.`vue_trois` to 'roletwo'@'localhost'
--------------
 
--------------
drop user if exists   'userone'@'localhost'
--------------
 
--------------
drop user if exists   'usertwo'@'localhost'
--------------
 
--------------
drop user if exists 'userthree'@'localhost'
--------------
 
--------------
create user   'userone'@'localhost' IDENTIFIED by 'userone'
--------------
 
--------------
create user   'usertwo'@'localhost' IDENTIFIED by 'usertwo'
--------------
 
--------------
create user 'userthree'@'localhost' IDENTIFIED by 'userthree'
--------------
 
--------------
grant usage on *.* to   'userone'@'localhost'
--------------
 
--------------
grant usage on *.* to   'usertwo'@'localhost'
--------------
 
--------------
grant usage on *.* to 'userthree'@'localhost'
--------------
 
--------------
grant 'roleone'@'localhost' to   'userone'@'localhost'
--------------
 
--------------
grant 'roletwo'@'localhost' to   'usertwo'@'localhost'
--------------
 
--------------
grant 'roleone'@'localhost' to 'userthree'@'localhost'
--------------
 
--------------
SET DEFAULT ROLE ALL TO 'userone'@'localhost','usertwo'@'localhost','userthree'@'localhost'
--------------
 
--------------
SET ROLE DEFAULT
--------------
 
--------------
flush privileges
--------------
 
--------------
SHOW GRANTS FOR   'userone'@'localhost'
--------------
 
+------------------------------------------------------+
| Grants for userone@localhost                         |
+------------------------------------------------------+
| GRANT USAGE ON *.* TO `userone`@`localhost`          |
| GRANT `roleone`@`localhost` TO `userone`@`localhost` |
+------------------------------------------------------+
--------------
SHOW GRANTS FOR   'usertwo'@'localhost'
--------------
 
+------------------------------------------------------+
| Grants for usertwo@localhost                         |
+------------------------------------------------------+
| GRANT USAGE ON *.* TO `usertwo`@`localhost`          |
| GRANT `roletwo`@`localhost` TO `usertwo`@`localhost` |
+------------------------------------------------------+
--------------
SHOW GRANTS FOR 'userthree'@'localhost'
--------------
 
+--------------------------------------------------------+
| Grants for userthree@localhost                         |
+--------------------------------------------------------+
| GRANT USAGE ON *.* TO `userthree`@`localhost`          |
| GRANT `roleone`@`localhost` TO `userthree`@`localhost` |
+--------------------------------------------------------+
--------------
SHOW GRANTS FOR   'roleone'@'localhost'
--------------
 
+-------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for roleone@localhost                                                                                                                    |
+-------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `roleone`@`localhost`                                                                                                     |
| GRANT SELECT ON `base`.`vue_trois` TO `roleone`@`localhost`                                                                                     |
| GRANT SELECT (`id`, `lib`, `val`), INSERT (`id`, `lib`, `val`), UPDATE (`id`, `lib`, `val`), DELETE ON `base`.`vue_un` TO `roleone`@`localhost` |
+-------------------------------------------------------------------------------------------------------------------------------------------------+
--------------
SHOW GRANTS FOR   'roletwo'@'localhost'
--------------
 
+-------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for roletwo@localhost                                                                                                              |
+-------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `roletwo`@`localhost`                                                                                               |
| GRANT SELECT (`id`, `lib`, `num`), INSERT (`id`, `lib`, `num`), UPDATE (`id`, `lib`, `num`) ON `base`.`vue_deux` TO `roletwo`@`localhost` |
| GRANT SELECT ON `base`.`vue_trois` TO `roletwo`@`localhost`                                                                               |
+-------------------------------------------------------------------------------------------------------------------------------------------+
--------------
COMMIT
--------------
 
Appuyez sur une touche pour continuer...

La suite ci-après.

Cordialement.
Artemus24.
@+

Re-Salut Laurent1133.

Le coeur de la bonne gestion des views repose sur les privilèges.
Si chaque utilisateur avait ses propres privilèges, il ne serait pas utilise de restreindre les accès des view.
Mais j'ai considéré qu'un utilisateur appartient à un seul groupe et donc restreindre les accès au groupe.
C'est pourquoi, une ligne ne sera accessible que si le groupe d'accès (le rôle) est le même que celui qui n'a créé.

On peut faire plus compliqué avec plusieurs groupes d'appartenance pour un utilisateur.
Et encapuslation des groupes sur plusieurs niveaux.
Par exemple, un utilisateur appartient au groupe du personnel.
Tous les utilisateurs ne sont pas des employés de l'entreprise.
Et ce même utilisateur appartient au groupe de la comptabilité ainsi qu'à l'audit où les accès sont de plus haut niveau.
On peut gérer les groupes par l'intermédiaire d'une table où celle-ci va nous autoriser ou pas à lire la ligne ou pas.

La bonne façon de faire est d'interdire l'accès directe aux tables.
Tu n'es pas obligé d'associer, comme je l'ai fait, les view aux rôles.
Mais tu peux mettre des privilèges directement sur les bases, les tables ou restreindre sur les colonnes.
Il faut dans ce cas définir la stratégie de sécurité à mettre en place.

Il va de soi que la base de données ainsi que les rôles ne doivent pas être accessible directement aux utilisateurs, sinon cela ne sert strictement à rien.
Tout doit se faire par l'intermédiaire des applications.

Afin de distinguer l'appartenance à un groupe, en fait le rôle qui est lié à l'utilisateur, je l'affiche dans le script mysql.
Dans chacun de mes scripts suivants, l'accès se fait à partir de l'userid et du password que j'ai donné dans les privilèges.

Voici l'accès de l'utilisateur "userone" :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
mysql: [Warning] Using a password on the command line interface can be insecure.
--------------
START TRANSACTION
--------------
 
--------------
SELECT CURRENT_ROLE()
--------------
 
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `roleone`@`localhost` |
+-----------------------+
--------------
select * from `article`
--------------
 
ERROR 1142 (42000) at line 6: La commande 'SELECT' est interdite à l'utilisateur: 'userone'@'@localhost' sur la table 'article'
--------------
INSERT INTO `vue_un`   (`lib`,`val`) VALUES ('Un',17.34)
--------------
 
--------------
INSERT INTO `vue_deux` (`lib`,`num`) VALUES ('Un',24.11)
--------------
 
ERROR 1142 (42000) at line 9: La commande 'INSERT' est interdite à l'utilisateur: 'userone'@'@localhost' sur la table 'vue_deux'
--------------
select * from `vue_un`
--------------
 
+----+-----+-------+
| id | lib | val   |
+----+-----+-------+
|  1 | Un  | 17.34 |
+----+-----+-------+
--------------
select * from `vue_deux`
--------------
 
ERROR 1142 (42000) at line 12: La commande 'SELECT' est interdite à l'utilisateur: 'userone'@'@localhost' sur la table 'vue_deux'
--------------
select * from `vue_trois`
--------------
 
+----+-----+-------+------+---------------------+---------------------+-------------------+-------------------+
| id | lib | val   | num  | created             | updated             | creator           | group             |
+----+-----+-------+------+---------------------+---------------------+-------------------+-------------------+
|  1 | Un  | 17.34 | 0.00 | 2023-03-13 12:59:35 | 2023-03-13 12:59:35 | userone@localhost | roleone@localhost |
+----+-----+-------+------+---------------------+---------------------+-------------------+-------------------+
--------------
commit
--------------
 
Appuyez sur une touche pour continuer...

Le rôle du "userone" est bien "roleone" comme conevnu.
Il peut utiliser la view "vue_un" mais pas la view "vue_deux".
Il n'est pas autorisé à lire la table "article" directement.
Le vidage ("vue_trois") nous montre le "creator" et le "group".
Je n'utilise pas le "creator" mais uniquement le "group" pour les sélections.

Ensuite, l'accès de l'utilisateur "usertwo" :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
mysql: [Warning] Using a password on the command line interface can be insecure.
--------------
START TRANSACTION
--------------
 
--------------
SELECT CURRENT_ROLE()
--------------
 
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `roletwo`@`localhost` |
+-----------------------+
--------------
select * from `article`
--------------
 
ERROR 1142 (42000) at line 6: La commande 'SELECT' est interdite à l'utilisateur: 'usertwo'@'@localhost' sur la table 'article'
--------------
INSERT INTO `vue_un`   (`lib`,`val`) VALUES ('Un',12.25)
--------------
 
ERROR 1142 (42000) at line 8: La commande 'INSERT' est interdite à l'utilisateur: 'usertwo'@'@localhost' sur la table 'vue_un'
--------------
INSERT INTO `vue_deux` (`lib`,`num`) VALUES ('Un',56.72)
--------------
 
--------------
select * from `vue_un`
--------------
 
ERROR 1142 (42000) at line 11: La commande 'SELECT' est interdite à l'utilisateur: 'usertwo'@'@localhost' sur la table 'vue_un'
--------------
select * from `vue_deux`
--------------
 
+----+-----+-------+
| id | lib | num   |
+----+-----+-------+
|  2 | Un  | 56.72 |
+----+-----+-------+
--------------
select * from `vue_trois`
--------------
 
+----+-----+-------+-------+---------------------+---------------------+-------------------+-------------------+
| id | lib | val   | num   | created             | updated             | creator           | group             |
+----+-----+-------+-------+---------------------+---------------------+-------------------+-------------------+
|  1 | Un  | 17.34 |  0.00 | 2023-03-13 12:59:35 | 2023-03-13 12:59:35 | userone@localhost | roleone@localhost |
|  2 | Un  |  0.00 | 56.72 | 2023-03-13 13:02:39 | 2023-03-13 13:02:39 | usertwo@localhost | roletwo@localhost |
+----+-----+-------+-------+---------------------+---------------------+-------------------+-------------------+
--------------
commit
--------------
 
Appuyez sur une touche pour continuer...

L'utilisateur "usertwo" a le rôle "roletwo" comme il se doit.
Il n'est pas autorisé à lire la table "article" directement.
Il peut uiliser la view "vue_deux" mais pas la view "vue_un".
Dans le vidage ("Vue_trois"), l'utilisateur "usertwo" a bien le rôle "roletwo".

J'ai volontairement mis le libellé à "Un" afin de voir ce qui va se passer si je désire modifier la colonne "val" comme dans l'exemple ci-après.

Voici l'accès de l'utilisateur "userone" :

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
mysql: [Warning] Using a password on the command line interface can be insecure.
--------------
START TRANSACTION
--------------
 
--------------
SELECT CURRENT_ROLE()
--------------
 
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `roleone`@`localhost` |
+-----------------------+
--------------
UPDATE `vue_un` SET `val` = 123.45 WHERE `lib` = 'Un'
--------------
 
--------------
select * from `vue_un`
--------------
 
+----+-----+--------+
| id | lib | val    |
+----+-----+--------+
|  1 | Un  | 123.45 |
+----+-----+--------+
--------------
select * from `vue_trois`
--------------
 
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
| id | lib | val    | num   | created             | updated             | creator           | group             |
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
|  1 | Un  | 123.45 |  0.00 | 2023-03-13 12:59:35 | 2023-03-13 13:06:44 | userone@localhost | roleone@localhost |
|  2 | Un  |   0.00 | 56.72 | 2023-03-13 13:02:39 | 2023-03-13 13:02:39 | usertwo@localhost | roletwo@localhost |
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
--------------
commit
--------------
 
Appuyez sur une touche pour continuer...

J'ai demandé de modifier la colonne "val" et celle-ci n'a été impacté que pour le groupe de l'utiilisateur "userone" et c'est ce que je désirais obtenir.

Accès de l'utilisateur "usertwo" :

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
43
44
45
46
47
48
mysql: [Warning] Using a password on the command line interface can be insecure.
--------------
START TRANSACTION
--------------
 
--------------
SELECT CURRENT_ROLE()
--------------
 
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `roletwo`@`localhost` |
+-----------------------+
--------------
select * from `article`
--------------
 
ERROR 1142 (42000) at line 6: La commande 'SELECT' est interdite à l'utilisateur: 'usertwo'@'@localhost' sur la table 'article'
--------------
DELETE FROM `vue_deux` WHERE `lib` = 'un'
--------------
 
ERROR 1142 (42000) at line 8: La commande 'DELETE' est interdite à l'utilisateur: 'usertwo'@'@localhost' sur la table 'vue_deux'
--------------
select * from `vue_deux`
--------------
 
+----+-----+-------+
| id | lib | num   |
+----+-----+-------+
|  2 | Un  | 56.72 |
+----+-----+-------+
--------------
select * from `vue_trois`
--------------
 
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
| id | lib | val    | num   | created             | updated             | creator           | group             |
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
|  1 | Un  | 123.45 |  0.00 | 2023-03-13 12:59:35 | 2023-03-13 13:06:44 | userone@localhost | roleone@localhost |
|  2 | Un  |   0.00 | 56.72 | 2023-03-13 13:02:39 | 2023-03-13 13:02:39 | usertwo@localhost | roletwo@localhost |
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
--------------
commit
--------------
 
Appuyez sur une touche pour continuer...

L'utilisateur "usertwo" ne peut pas supprimer de lignes car il n'est pas autorisé à le faire, et c'est très bien.

Et pour finir, accès de l'utilisateur "userthree" qui est du même groupe que l'utilisateur "userone".

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
43
44
45
46
47
48
mysql: [Warning] Using a password on the command line interface can be insecure.
--------------
START TRANSACTION
--------------
 
--------------
SELECT CURRENT_ROLE()
--------------
 
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `roleone`@`localhost` |
+-----------------------+
--------------
select * from `article`
--------------
 
ERROR 1142 (42000) at line 6: La commande 'SELECT' est interdite à l'utilisateur: 'userthree'@'@localhost' sur la table 'article'
--------------
select * from `vue_un`
--------------
 
+----+-----+--------+
| id | lib | val    |
+----+-----+--------+
|  1 | Un  | 123.45 |
+----+-----+--------+
--------------
select * from `vue_deux`
--------------
 
ERROR 1142 (42000) at line 8: La commande 'SELECT' est interdite à l'utilisateur: 'userthree'@'@localhost' sur la table 'vue_deux'
--------------
select * from `vue_trois`
--------------
 
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
| id | lib | val    | num   | created             | updated             | creator           | group             |
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
|  1 | Un  | 123.45 |  0.00 | 2023-03-13 12:59:35 | 2023-03-13 13:06:44 | userone@localhost | roleone@localhost |
|  2 | Un  |   0.00 | 56.72 | 2023-03-13 13:02:39 | 2023-03-13 13:02:39 | usertwo@localhost | roletwo@localhost |
+----+-----+--------+-------+---------------------+---------------------+-------------------+-------------------+
--------------
commit
--------------
 
Appuyez sur une touche pour continuer...

Comme on peut le constater, il peut utiliser la view "vue_un" mais pas la view "vue_deux".

Voilà un petit exemple de gestion des privilèges au travers des views.
J'espère avoir répondu à ta question. :)

Cordialement.
Artemus24.
@+

14/03/2023, 19h35
laurent1133

Vues

Woaw Un grand merci Artemus24. 'c'est quasi un tutoriel'.