Discussion :

[oraya]

Bonjour bonjour

J'ai une problématique d'ordre conceptuelle pour vous.
Je m'intéresse depuis peu à la gestion des utilisateurs dans une base de donnée. Jusqu'à maintenant, je gérais ça "à la main" on va dire, via une table que j'ai crée moi même.

Mais ce que je souhaite faire maintenant c'est limiter l'accès aux utilisateurs à certaines parties de la BDD, en particulier certains champs d'une table.
Rien de plus simple me direz-vous, il suffit de donner des privilèges limités à cet utilisateur :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE table1 (
	key INT NOT NULL,
	champ1 VARCHAR(30),
	champ2 VARCHAR(30),
	PRIMARY KEY (key)
);
CREATE USER toto@localhost IDENTIFIED BY 'averystrongpassword';
GRANT SELECT(key, champ1) ON table1 TO toto@localhost;

Seulement voila, j'ai aussi besoin d'effectuer une selection sur cette table. Comme il est impossible d'allier l'instruction WHERE avec GRANT, la solution parfaite est de faire une vue.
On change donc de méthode et on adopte :

Code :

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

1
2
3
4
5
CREATE VIEW view1 AS
SELECT key, champ1
FROM table1
WHERE champ2 = "value";
GRANT SELECT ON view1 TO toto@localhost;

Maintenant tout à l'air parfait, mon utilisateur ne peux sélectionner que certaines données. Plus besoin donc de se poser des questions de sécurité à ce niveau la (car oui c'est le but de la manoeuvre en fin de compte).

Moi, en tant que dév Web, j'ai besoin de développer une magnifique appli web sur laquelle mon utilisateur 'toto' va se connecter.
Cette vue représentant des données qui seront chargées dans une variable de session, je vais donc écrire mon petit algo :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
$query = $bdd->prepare(
	"SELECT *
	FROM view1"
);
$query->execute();
$data = $query->fetchAll(PDO::FETCH_ASSOC);
$query->closeCursor();
 
session_name($cookie);
session_start();// Démarre la session
 
foreach ($data as $key => $value)
	$_SESSION[$key] = $data[$key];

Tout marche bien, tout est beau dans le meilleur des mondes.

Sauf que moi, j'ai quand même envie que plusieurs utilisateurs différents se connectent à mon site ^^
Alors créer des vues de manière dynamique à la création d'un compte, pourquoi pas. Mais comment diable est-ce que je vais faire pour que dans ma page PHP, ma requête pointe sur la bonne vue associée à l'utilisateur qui se connecte ?

On pourrait se dire, tu sélectionnes toute les vues de ta base sur lesquelles t'a des droits et tu prends que celle qui t'intéresse, en la choisissant par exemple en fonction d'un pattern dans son nom.
Ou encore, tu fais une magnifique table associative de tes users et de leurs vues respectives.
Mais bon ça me parait très "bricolo" tout ça xD Par pitié dites moi que c'est pas mes seules options

Je débute sur ce genre de problématique, mais je suis persuadé que c'est quelque chose qui a déjà été pensé, c'est juste que j'en connait pas la réponse
Quel est le consensus général dans ce genre de cas ? Qu'elle méthode adoptent les architectes Web ?

Merci à tout ceux qui prendrons le temps de me lire

PS : d'ailleurs si quelqu'un saurait aussi comment faire récupérer quelque chose comme un identifiant utilisateur ? les utilisateurs mysql sont enregistrés dans une autre base, "mysql". Pour l'instant j'ai juste rajouté une colonne dans ma table avec le nom de l'utilisateur pour faire ma jointure, mais j'aimerai quelque chose de plus solide qu'un simple nom ^^

[Sebwar]

Hello !

Tu peux gérer les droits au niveau des tables et des colonnes dans la base "mysql".
ainsi pour une même vue, deux utilisateurs n'auront pas forcement accès aux mêmes champs.

[oraya]

Salut ^^

Certes, mais ce dont j'ai besoin c'est d'une vue en fonction d'une valeur d'un champs, d'où le

Code :

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

WHERE champ2 = "value";

Un cas pratique serais de dire, on sélectionne uniquement les données affiliées à un identifiant d'utilisateur :

Code :

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

WHERE Id = "id_user";

Ca ne me pose pas trop de problème de créer une vue par utilisateur (quoique si une meilleure solution existe, je suis preneur ^^), mais la où c'est embêtant, c'est lors du développement de l'IHM, dans laquelle j'ai besoin d'accéder dynamiquement à une vue

[al1_24]

Si la restriction doit être effectuée au niveau de la colonne à l'intérieur de la vue, tu peux passer par une expression pour ces colonnes.
Quelque chose de cette forme :

Code :

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

1
2
3
SELECT  col_publique
    ,   CASE WHEN USER = user_autorisé THEN col_privée ELSE 'masqué' END AS col_privée
FROM    ...

Tu peux étendre ce modèle avec une table qui spécifie pour chaque utilisateur les colonnes qu'il a le droit de voir, etc...

[escartefigue]

Bonjour,

Créez vos droits non pas au niveau des utilisateurs, mais au niveau des profils, et associez ensuite vos utilisateurs à ces profils

Exemple :
Profil admin : tous les droits via la vue V1
Profil utilisateur : droits restreints via la vue V2

Logins : L1, L5 et L6 sont rattachés au profil admin
les autres sont rattachés au profil utilisateur

Dans cet exemple, 2 profils et donc 2 vues seulement sont nécessaires

A vous de tester le code profil de la personne lors de sa signature dans l'application.

[oraya]

Je vous remercie pour ces réponses

Hmm... Je pense que ma demande est légèrement ambigüe.
Mon but n'est pas d'effectuer une restriction au niveau d'une colonne ou bien d'avoir différents niveaux d'accréditation sur ma base de donnée.
Je vais essayer de reformuler ^^

L'objectif est de déplacer la gestion des utilisateurs au niveau de la base de donnée elle même, de faire en sorte qu'a un utilisateur de mon application Web soit associé un user de ma BDD. Ainsi je laisse MySQL s'occuper de l'authentification pour moi. Lorsqu'un utilisateur s'authentifie, il s'authentifie directement envers la BDD, en tant qu'utilisateur ce cette BDD (peut être d'ailleurs est-ce une mauvaise interprétation de ma part de ce qu'est un utilisateur dans une base de données).

Maintenant, j'ai besoin d'associer des données à ces utilisateurs. Prenons une table X(key, user, champs...) avec comme clé primaire (key, user).
Lorsqu'un utilisateur a besoin d'accéder à ses données, j'aimerai qu'il puisse sélectionner dans cette table l'ensemble des colonnes (et donc key, champs...), sauf la colonne 'user', qui servira alors à déterminer quelles données appartiennent à quels utilisateur. Ainsi, une vue parfaite pour l'utilisateur 'toto' serais :

Code :

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

1
2
3
4
CREATE VIEW view1 AS
SELECT key, champs...
FROM table1
WHERE user = "toto";

Le problème est le caractère "statique" de la sélection WHERE user = "toto".

Pour le moment, je fait une simple requête dans mon appli Web, avec comme critère de sélection le login de l'utilisateur qui s'est connecté.

Code :

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

1
2
3
SELECT key, champs...
FROM table1
WHERE user = "login"

Mais le souci avec cette méthode est que la restriction d'accès aux données est effectuée au niveau de l'interface. L'utilisateur peux alors s'il le souhaite, envoyer une requête à la BDD de son côté (en utilisant une autre appli par exemple), et avoir accès aux données des autres utilisateurs (car au final, il a accès à l'ensemble de la table).

Ma question donc était principalement de savoir s'il existe une méthode ou technique (implicite à la BDD) pour lier un utilisateur de cette BDD non pas à des colonnes (cas d'une vue), mais bien à des lignes.

J'espère que ces détails pourront vous être utiles
N'hésitez pas si vous avez besoin d'une quelconque explication supplémentaire

[skuatamad]

Le problème c'est que vous utilisez mysql qui n'a pas beaucoup de fonctionnalité, et pour lequel il manque la notion de schéma.
Vous pouvez peut être vous en sortir avec la fonction user(), quelque chose comme ça :

Code :

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

1
2
3
4
CREATE VIEW view1 AS
SELECT key, champs...
  FROM table1
 WHERE user =SUBSTRING_INDEX(USER(),'@',1);;

Vous pouvez peut être aussi vous inspirer de cet article :
MySQL 5.0 Fine-Grained Access Control (FGAC)

Et pour vos recherches complémentaires, utilisez le terme Fine-Grained Access Control qui correspond à ce que vous souhaitez implémenter.

[Artemus24]

Salut à tous.

Je suppose que vous avez pris le problème à l'envers.
Vous avez commencé par écrire votre application, puis ensuite vous vous posez des questions sur les problèmes de sécurités.
Et maintenant, vous vous retrouvez coincé sur la faisabilité de votre problème de permissions.

Jusqu'à maintenant, je gérais ça "à la main" on va dire, via une table que j'ai crée moi même.

Non, c'est une erreur de procéder ainsi car vous n'aurez pas la sécurité que vous attendez.

Mais ce que je souhaite faire maintenant c'est limiter l'accès aux utilisateurs à certaines parties de la BDD, en particulier certains champs d'une table.

La solution est de créer une view. Et d'attribuer à cette view, les permissions.

Rien de plus simple me direz-vous, il suffit de donner des privilèges limités à cet utilisateur

Non, justement ce n'est pas aussi simple que cela.

Pour résoudre votre problème, vous devez définir des groupes d'utilisateurs. C'est ce que nomme Escartefigue, des profiles.
La question que vous devez vous poser, c'est l'identification de l'utilisateur avant de se connecter à la base de données.
Vous devez créer une table d'association entre cet identifiant et le groupe de travail final.
Lors de la connexion, vous allez spécifier ce groupe de travail (le profile) qui est déclaré dans phpmyadmin pour la table user.

Est-ce qu'il y a moyen de frauder cet identifiant ? Question crucial ! Je ne saurais répondre sans exemple.
L'utilisateur ne doit pas avoir accès à la table association, soit par phpmyadmin, soit hors application, ou dans votre application.

Ensuite, chaque groupe de travail aura ses propres privilèges.
Il faudra passer en revue pour chaque table et chaque view que vous avez créé, les privilèges que vous désirez obtenir pour chaque groupe de travail.

Par exemple, pour le groupe des utilisateurs, aucun accès à la table T1, mais un accès à la view V1, qui travaille sur cette table.

Plus vous allez descendre dans vos permissions, plus vous allez obtenir des cas particuliers. Ce qui va devenir ingérable si vous avez trop de groupes à gérer.

Hmm... Je pense que ma demande est légèrement ambigüe.

Ambigüe, non. Mais devenir une usine à gaz, oui.

Ma question donc était principalement de savoir s'il existe une méthode ou technique (implicite à la BDD) pour lier un utilisateur de cette BDD non pas à des colonnes (cas d'une vue), mais bien à des lignes.

A ma connaissance, on ne peut pas restreinde l'accès d'un utilisateur à des lignes, s'il effectue un select directement sur une table.
Pour résoudre ce problème, il faut utiliser une View. Oui, mais voilà, que mettre dans une view ?

Imaginez que vous ayez 200 utilisateurs, vous n'allez pas créer 200 comptes sous MySql, ni pour une view donnée, créer 200 view dérivées.
Ensuite, il y a le problème de la view. Si celle-ci travaille toujours sur les mêmes colonnes, mais pas les mêmes lignes, qui sont conditionnées par une constante, comme dans votre exemple avec 'user', il faudrait dans ce cas là, produire dynamiquement cette view.
Genre, faire un requête préparée. Oui, mais question sécurité, cela ne va pas fonctionner car qu'est-ce qui empêche l'utilisateur de créer en ligne de commande un accès à la base et de recréer la view avec un autre 'user' ?
Rien ne l'empêche car comme je vous l'ai dit, à ma connaissance, il n'y a pas de restriction sur les lignes.

Vu comme vous posez votre problème, je ne voie aucune solution à votre problème de sécurité.

@+

[oraya]

Je suppose que vous avez pris le problème à l'envers.
Vous avez commencé par écrire votre application, puis ensuite vous vous posez des questions sur les problèmes de sécurités.
Et maintenant, vous vous retrouvez coincé sur la faisabilité de votre problème de permissions.

En effet c'est comme ça que ça s'est passé au début, d'où le fait que je me pose ces questions maintenant que j'ai commencé une nouvelle structure

La solution est de créer une view. Et d'attribuer à cette view, les permissions.

Tout à fait d'accord, c'est la solution qui me semblait la plus adaptée. Mais comme vous l'avez dit ça risque vite de devenir une magnifique usine a gaz ^^

Plus vous allez descendre dans vos permissions, plus vous allez obtenir des cas particuliers. Ce qui va devenir ingérable si vous avez trop de groupes à gérer.
...
Ambigüe, non. Mais devenir une usine à gaz, oui.

C'est la tout l'intérêt de ce topic, je voulais savoir comment éviter ça et quelle est l'erreur dans ma démarche. Et comme je m'en doutait :

A ma connaissance, on ne peut pas restreinde l'accès d'un utilisateur à des lignes, s'il effectue un select directement sur une table.
Pour résoudre ce problème, il faut utiliser une View.

Imaginez que vous ayez 200 utilisateurs, vous n'allez pas créer 200 comptes sous MySql

En réalité, c'est la mon intention Que chaque utilisateur aie un compte distinct sous MySQL, pour ne pas avoir à gérer l'authentification.
Ce que je ne sait pas en revanche c'est si effectivement c'est une erreur d'agir ainsi, et si oui pourquoi ?
J'essaie justement d'éviter de devoir créer et gérer des groupes d'utilisateurs et/ou table associative, vu que je n'en ai pas spécialement besoin dans mon application (même si, je vous l'accorde, ça représente un design pattern solide et utile ^^)

Vu comme vous posez votre problème, je ne voie aucune solution à votre problème de sécurité.

En fait, skuatamad a très bien cerné mon besoin et la solution qu'il offre semble être appropriée dans mon cas Pour ce que j'en ai testé pour l'instant, ça à l'air de fonctionner Je vais aller jetter un coup d'oeil du côté de Fine-Grained Access Control sur ses conseils.

Merci à vous deux d'avoir prit le temps de me répondre !

Je reviens vers vous tous très bientôt pour vous dire si je peux adopter la solution skuatamad ou si à l'inverse, la solution Artemus24 / Escartefigue est ma seule option

Bye !

[Artemus24]

Salut oraya.

En réalité, c'est la mon intention Que chaque utilisateur aie un compte distinct sous MySQL, pour ne pas avoir à gérer l'authentification.

Mais vous êtes quand même obligé de vous authentifier pour accéder à MySql.
C'est le rôle de la connexion de définir sous quel compte et avec quelles permissions vous accédez à votre base de données.
Et j'espère pour vous, que vous n'utilisez pas le compte 'root' ! Rassurez moi.

J'essaie justement d'éviter de devoir créer et gérer des groupes d'utilisateurs et/ou table associative, vu que je n'en ai pas spécialement besoin dans mon application

Pour vous connecter, vous avez besoin d'un compte MySql ! Pour les utilisateurs, on met en général : select, insert, update et delete sur la totalité de la base.
Maintenant, vous désirez restreindre les accès au niveau des données. C'est faisable sur les colonnes, mais pas sur les lignes.

En fait, skuatamad a très bien cerné mon besoin et la solution qu'il offre semble être appropriée dans mon cas

Non ! User() vous donne le compte mysql de connexion et non le compte windows ou autre chose.
Si à la connexion, vous mettez "root@localhost" et bien tous les utilisateurs auront "root" comme compte.

Returns the current MySQL user name and host name as a string in the utf8 character set.

Code :

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

1
2
mysql> SELECT USER();
        -> 'davida@localhost'

The value indicates the user name you specified when connecting to the server, and the client host from which you connected. The value can be different from that of CURRENT_USER().

Pour ce que j'en ai testé pour l'instant, ça à l'air de fonctionner

Dois-je comprendre que vous avez déjà un compte mysql par utilisateur ?
Car si ce n'est pas le cas, l'astuce de skuatamad ne sert à rien (je parle de la view du post #7).

Je tiens à préciser la structure de la table qui est en exemple, est celle-ci :

Code :

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

1
2
3
4
5
6
+------+-------------+-------+
| num  | expire_date | owner |
+------+-------------+-------+
| 1234 | 2006-12-22  | userA |
| 5678 | 2006-12-22  | userB |
+------+-------------+-------+

L'utilisateur A désire accéder à cette table, au travers d'une view, celle de skuatamad.
Comment faire pour que l'utilisateur B ne puisse pas accéder aux informations de l'utilisateur A ?
Si vous connaissez les identifiants de connexion, n'importe qui pourra créer en ligne de commandes, un accès et visualiser ce qu'il veut dans cette table.
Pourquoi ? Car MySql ne sait pas gérer les restrictions sur les lignes. Conclusion : aucune sécurité possible sur la ligne.

@+

[oraya]

Bonjour tout le monde ^^
C'est bon j'ai testé, tout fonctionne bien Merci à skuatamad pour cette solution. J'avais un peu peur que la fonction USER() soit évaluée à la création de la vue et non à la volée.

Pour répondre à Artemus24, je pense qu'on ne se comprend pas vraiment sur certains points. J'ai l'impression qu'on utilise les mêmes termes mais qu'ils ont des significations différentes pour chacun de nous ^^

Mais vous êtes quand même obligé de vous authentifier pour accéder à MySql.
C'est le rôle de la connexion de définir sous quel compte et avec quelles permissions vous accédez à votre base de données.
Et j'espère pour vous, que vous n'utilisez pas le compte 'root' ! Rassurez moi.

Je suis entièrement d'accord avec vous, il faut s'authentifier pour accéder à MySql. Et non effectivement, je n'utilise pas le compte 'root' xD Ce serais déraisonnable
Lorsque je parle ne pas avoir à gérer l'authentification, j'entends ne pas avoir à concevoir moi même des fonctions pour gérer l'encryptage/décryptage de mots de passe, ni même de faire de vérification dans la BDD par rapport à l'utilisateur qui se connecte.
Ce que je fait en réalité, c'est déléguer totalement l'authentification au serveur MySQL. Dans mon formulaire de connexion, j'envoie directement les valeurs de $_POST["login"] et $_POST["pass"] à la fonction

Code :

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

1
2
3
4
5
6
$bdd = new PDO(
	'mysql:host=localhost:xxxx; dbname=test; charset=utf8',
	$_POST["login"],
	$_POST["pass"],
	array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION)
)

C'est comme si l'utilisateur se connectait directement au serveur MySQL, l'interface web ne servant au final que de passerelle.

Pour vous connecter, vous avez besoin d'un compte MySql ! Pour les utilisateurs, on met en général : select, insert, update et delete sur la totalité de la base.

Oui oui, je sais bien
Quand je parle de groupes d'utilisateurs et/ou table associative, je veux encore une fois parler d'une implémentation que j'aurais fait moi même, avec par exemple une table d'utilisateur associés à des noms de groupes etc...
Ici, j'ai l'impression que pour vous, "compte mysql" et "groupes d'utilisateurs" signifie la même chose.
Pour moi, un "compte mysql" correspondrait dans mon architecture à un "utilisateur final" du système. "CREATE USER" voudrait alors vraiment dire "créer un utilisateur".

Non ! User() vous donne le compte mysql de connexion et non le compte windows ou autre chose.
Si à la connexion, vous mettez "root@localhost" et bien tous les utilisateurs auront "root" comme compte.

Je sais bien xD Et c'est justement le but Que le résultat de cette fonction serve de clé de sélection aux données.
Maintenant, je vous l'accorde, ça fait un peu bricolage comme solution, c'est pour ça que je vais continuer de chercher quelque chose de plus adapté.
Mais pour l'heure, ça résout mes questions de sécurité ^^

Dois-je comprendre que vous avez déjà un compte mysql par utilisateur ?
Car si ce n'est pas le cas, l'astuce de skuatamad ne sert à rien (je parle de la view du post #7).

Oui en effet, c'est le cas. On parle bien sûr ici de 2 utilisateurs pour l'instant, mais qui pourrons être bien plus dans l'avenir.
Encore une fois, je ne sais pas s'il est correct d'utiliser les USER MySQL de la sorte, ou si ça représente une utilisation détournée. J'aimerais bien plus de détails la dessus

Je tiens à préciser la structure de la table qui est en exemple, est celle-ci :

Code :

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

1
2
3
4
5
6
+------+-------------+-------+
| num  | expire_date | owner |
+------+-------------+-------+
| 1234 | 2006-12-22  | userA |
| 5678 | 2006-12-22  | userB |
+------+-------------+-------+

L'utilisateur A désire accéder à cette table, au travers d'une view, celle de skuatamad.
Comment faire pour que l'utilisateur B ne puisse pas accéder aux informations de l'utilisateur A ?
Si vous connaissez les identifiants de connexion, n'importe qui pourra créer en ligne de commandes, un accès et visualiser ce qu'il veut dans cette table.
Pourquoi ? Car MySql ne sait pas gérer les restrictions sur les lignes. Conclusion : aucune sécurité possible sur la ligne.

Solution :

Un bon exemple vaut mieux qu'on long discours Je vais dérouler ici ma démarche pour vous donner l'exemple qui fonctionne pour moi. Un peu de code SQL ça fait pas de mal :p

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
mysql> CREATE USER userA;
mysql> CREATE USER userB;   // Pas de password, question de facilité pour l exemple
 
mysql> CREATE TABLE table1 (
    -> id INT NOT NULL AUTO_INCREMENT,
    -> user CHAR(16) NOT NULL,
    -> champ VARCHAR(30),
    -> PRIMARY KEY (id, user)
    -> );
mysql> INSERT INTO table1(user, champ)
    -> VALUES
    -> ("userA", "J'habite à Paris"),
    -> ("userB", "J'habite à Monaco");
 
mysql> SELECT * FROM table1;
+----+-------+--------------------+
| id | user  | champ              |
+----+-------+--------------------+
|  1 | userA | J'habite à Paris   |
|  2 | userB | J'habite à Monaco  |
+----+-------+--------------------+
 
mysql> CREATE VIEW view1 AS
    -> SELECT id, champ
    -> FROM table1
    -> WHERE user = SUBSTRING_INDEX(USER(),'@',1);
 
mysql> GRANT SELECT ON view1 TO 'userA'@'localhost';
mysql> GRANT SELECT ON view1 TO 'userB'@'localhost';

Maintenant on se connecte en tant que "userB" :

Code :

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

1
2
3
4
5
6
7
8
$ mysql -h localhost -u userB test
mysql> SELECT * FROM view1;
+----+--------------------+
| id | champ              |
+----+--------------------+
|  2 | J'habite à Monaco  |
+----+--------------------+
1 row in set (0.01 sec)

Et en tant que "userA" :

Code :

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

1
2
3
4
5
6
7
8
$ mysql -h localhost -u userA test
mysql> SELECT * FROM view1;
+----+-------------------+
| id | champ             |
+----+-------------------+
|  1 | J'habite à Paris  |
+----+-------------------+
1 row in set (0.00 sec)

A la prochaine !

[Artemus24]

Salut oraya.

je pense qu'on ne se comprend pas vraiment sur certains points.

En faite, il existe plusieurs solutions pour déclarer un user sur un site web, soit sous apache, soit sous MySql ou soit vous gérez cela par vous même.
Ne comprenant pas bien le choix que vous avez fait au départ, j'ai eu du mal à envisager votre solution.

La solution de skuatamad basée sur les view est celle que l'on applique sur un SGBD pour gérer les permissions d'accès.
En plus, dans la table et dans la vue, il faut gérer le compte utilisateur autorisées pour telles ou telles lignes.
Est-ce que vous faites que de la consultation ou bien aussi des mises à jour sur vos tables ?

Lorsque je parle ne pas avoir à gérer l'authentification, j'entends ne pas avoir à concevoir moi même des fonctions pour gérer l'encryptage/décryptage de mots de passe, ni même de faire de vérification dans la BDD par rapport à l'utilisateur qui se connecte.

Vous formulez une certaine ambiguïté en disant ne pas gérer par vous même l'authentification (ou la connexion) sous MySql, alors que c'est le cas.
Par authentification, je parle bien de la déclarative que l'on fait en php, pour se connecter à la base de données.

Ce qui me manque, c'est le lien que vous avez choisi entre l'identification au niveau du site, et l'authentification à MySql ?
D'où viennent ces "login" et ces "password" ? Est-ce Apache qui gère ces identifications ? Ou est-ce une application Php/MySql qui gère cela (il me semble que non) ?
Or vous dites que vous ne gérez pas la partie encryptage / décryptage, ni des vérifications dans vos bases de données.
Comment être sûr que l'utilisateur qui tape son login/password est le bon ? C'est cette partie que je ne comprends pas.

Ici, j'ai l'impression que pour vous, "compte mysql" et "groupes d'utilisateurs" signifie la même chose.

Cela dépend de l'usage que vous en faite. Attribuer un compte à chaque utilisateur va complexifier la gestion des accès à MySql, sans apporter un réel avantage.
On crée plutôt un compte pour chaque type de permissions que l'on veut implémenter --> utilisateur avec pouvoir, utilisateur en consultation, administrateur, chef de groupe ...
C'est dans ce sens que j'attribue la notion de "groupe d'utilisateurs" à un compte MySql.

MySql ne sait pas gérer des groupes d'utilisateurs. A savoir, déclarer un user propre à un utilisateur, et lui affecter les permissions d'un groupe de travail donné.

ça fait un peu bricolage comme solution

Non. Car vous gérez les permissions au niveau de la ou des vues auquel(s) l'utilisateur accède.
Et comme vous avez besoin de la fonction 'user()', il est nécessaire de déclarer un compte pour chaque utilisateur.

c'est pour ça que je vais continuer de chercher quelque chose de plus adapté.

Il y a l'authentification par certificat SSL.
Mais cela ne va pas résoudre votre problème de permissions sur les tables / vues.

Mais pour l'heure, ça résout mes questions de sécurité

Par sécuritaire, il faut comprendre protection des données sur le réseau. Dans votre cas, il s'agit de problèmes de permissions.
Vous créez un filtre en faisant l'usage d'une view, associé au compte mysql d'identification. C'est la solution MySql, la plus adapté à ce que vous voulez faire.

Oui en effet, c'est le cas.

Je n'avais pas compris comment vous gériez les comptes MySql.

Encore une fois, je ne sais pas s'il est correct d'utiliser les USER MySQL de la sorte, ou si ça représente une utilisation détournée.

Passer par les vues pour attribuer les permissions est la bonne façon de faire.

Un bon exemple vaut mieux qu'on long discours

C'est aussi ma philosophie !

Pour gérer correctement les permissions, voici un exemple :

Code :

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

1
2
3
4
5
DROP   USER                                                'base'@'%';
CREATE USER                                                'base'@'%'   IDENTIFIED BY 'base';
GRANT  USAGE                          ON            *.* TO 'base'@'%';
GRANT  SELECT, INSERT, UPDATE, DELETE ON       `base`.* TO 'base'@'%';
SET    PASSWORD FOR 'base'@'%' = PASSWORD('base');

Ma base de données se nomme 'base', ainsi que le mot de passe.
En ligne de commande, pour exécuter une requête SQL, voici comment l'appeler :

Code :

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

mysql < test.sql  --verbose  --force  --user=user1  --password=  --host=localhost

J'ai lu et relu le lien donné par skuatamad. J'ai fait le test et cela fonctionne parfaitement à la condition de ne gérer que des view.
Mais quand est-il si vous faites des mises à jour sur vos tables ?

@+