Discussion :

[soad]

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]

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]

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]

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]

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]

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.

[Biglo]

et le WHERE utilisateur = USER() n'est-il pas interprété au moment de la création de la vue ?

Pas de soucis de ce côté. Les expressions sont interprétées à l'exécution de la requête.

[soad]

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

C'est vrai que coté maintenance c'est pas super !

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.

Les utilisateurs ne peuvent pas exécuter de code SQL mais le risque c'est qu'il se connecte avec autres chose que l'appli !


On peut faire des triggers avec les dernières version de mysql ou bien ?
Est ce qu'on peut déclencher un trigger sur une requête de sélection ?

[Biglo]

On peut faire des triggers avec les dernières version de mysql ou bien ?
Est ce qu'on peut déclencher un trigger sur une requête de sélection ?

On peut créer des triggers depuis la version 5, mais qui se déclenchent avant/après une insertion, modification ou suppression.

Que veux-tu faire ? Tu peux peut-être créer une procédure qui ferait le traitement que tu désires, puis qui génère le résultat du SELECT.

[Maximil ian]

Les utilisateurs ne peuvent pas exécuter de code SQL mais le risque c'est qu'il se connecte avec autres chose que l'appli !

Tu penses à quoi en particulier ? Question sécurité il me semble qu'il y a des parades bien plus efficaces et moins lourdes que ce que tu essaies de mettre en place...

[soad]

On peut créer des triggers depuis la version 5, mais qui se déclenchent avant/après une insertion, modification ou suppression.

Que veux-tu faire ? Tu peux peut-être créer une procédure qui ferait le traitement que tu désires, puis qui génère le résultat du SELECT.

En faite je pensais remplacer les vue par un trigger qui contrôle qu'on ne fasse pas un sélect sur des données autres que les siens ! Mais bon c'est plus simple les vue a mon avis !

Tu penses à quoi en particulier ? Question sécurité il me semble qu'il y a des parades bien plus efficaces et moins lourdes que ce que tu essaies de mettre en place...

Bon pour finir je pense que je vais faire des pages php qui ferons le liens entre mysql et mon appli ! comme ca j'aurais plus de problème !