[Utilisateur] bloquer des lignes

**soad** · 26/08/2006, 14h05

Hello tout le monde..

Est ce qu'il est possible de créer des utilisateurs sous mysql et de leur autorisé l'accès uniquement sur certaine ligne ?

par exemple uniquement sur les lignes qu'il ont créer eux meme ?

Si c'est pas possible comment faite vous pour protéger les données présent dans la base de donnée ?

merci

**Maximil ian** · 26/08/2006, 15h00

Salut,

Il n'est pas possible de savoir de manière simple qui a inséré telle ou telle ligne. En revanche on peut créer une vue qui ne comportera que certaines lignes de la table d'origine, et ne donner au user que les privilèges sur cette vue et pas la table (plus d'explications ici).

Sinon, par utilisateur tu entends utilisateur de la base de données ou de l'application ?

**Biglo** · 26/08/2006, 16h02

Bonjour,

J'aurais peut-être une solution, qui a certes ses inconvénients. Le premier étant qu'il faut utiliser MySQL >= 5.

Comme le dit Maximilian, on ne connaît pas qui a inséré les lignes. Donc la première chose à faire serait de rajouter une colonne "Utilisateur" (VARCHAR(80) devrait être bon) à la table. Ensuite, à chaque insertion, on appelle USER() pour stocker l'utilisateur qui exécute la requête :

Code :

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

INSERT INTO client VALUES (..., ..., USER());

Ensuite, on crée donc une vue où tous les utilisateurs auront le privilège SELECT :

Code :

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

CREATE VIEW mes_clients AS SELECT col1, col2, ... FROM client WHERE utilisateur = USER();

Eh voilà : à chaque fois qu'un utilisateur fera :

Code :

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

SELECT * FROM mes_clients

il obtiendra les infos des clients qu'il a insérés dans la table Client.

Les inconvénients qui me viennent à l'esprit :

si on modifie un utilisateur (username), il faut modifier la table Client
ca prend quand même beaucoup de place si on a beaucoup de clients !

**soad** · 26/08/2006, 19h35

Envoyé par Maximilian

Sinon, par utilisateur tu entends utilisateur de la base de données ou de l'application ?

Des utilisateurs de la base de donnée !

Pcq en faite j'aimerais faire une appli qui se connecte directement à la base ! Les utilisateurs auront un login et un mot de passe que j'aurais auparavant créer sous mysql !

Le problème avec l'enregistrement du user dans la table c'est que j'ai pas mal de table ! j'me vois pas trop le stoquer dans chaque !

Ou alors j'ai pensé faire une base de donnée par personne mais bon ca me parait un peu lourd, non ?

**Biglo** · 26/08/2006, 19h49

Envoyé par soad

Le problème avec l'enregistrement du user dans la table c'est que j'ai pas mal de table ! j'me vois pas trop le stoquer dans chaque !

Ou alors j'ai pensé faire une base de donnée par personne mais bon ca me parait un peu lourd, non ?

Ca prendra moins de place, c'est sûr. Mais à gérer, c'est sûrement pas mieux.

A chaque changement des utilisateurs (ajout par exemple), il va sûrement te falloir changer certaines tes requêtes pour prendre en compte la nouvelle base. Je pense notamment si tu as un utilisateur "admin" qui peut accéder à tous les enregistrements dans ton appli.

**Maximil ian** · 27/08/2006, 16h29

A mon avis tout dépend de ton appli :

- Si c'est une sorte de PHPMyAdmin où les utilisateurs saisissent des commandes SQL, alors tu seras obligé comme la plupart des hébergeurs d'avoir une table ou une base par user.
Tu peux tester la solution de Biglo mais c'est vrai que ça risque d'être un peu lourd au niveau performances (et le WHERE utilisateur = USER() n'est-il pas interprété au moment de la création de la vue ?)

- Pour une appli plus classique, avoir un user SGBD pour chaque user du programme est une assez mauvaise idée. En effet le SGBD n'est pas (encore ?) un outil assez perfectionné pour intégrer les règles de gestion selon lesquelles tel utilisateur a accès à telles ou telles données précises. Pour preuve les problèmes de privilèges sur des lignes.
Ce boulot relève plus de la logique métier codée dans l'application.