Bonjour,
je souhaitais simplement savoir si TOUTES les requetes, des plus simples aux plus compliquées, ayant pour but un affichage partiel ou complet des informations contenues dans la BDD, commencent par le mot clé SELECT.
Deuxieme question :
comment executer deux requetes en une seule (plus particulierement un delete ou un modify en meme temps qu'un select) ?
Merci,
Netsupra

Sur un plan très basique : il existe trois sortes de requêtes :

1. Les requête récupérant des données dans une base : "SELECT ..."
2. Les requêtes de modification pour mettre à jour des données existantes : "UPDATE ..."
3. Les requêtes de suppression de données : "DELETE ..."

On ne peut pas combiner ces requêtes en mélangeant tout ça dans une seule requête, on fait l'un ou l'autre... SAUF lorsqu'on utilise une sous-requête (SELECT) dans une clause de tri (WHERE ...)

Mais est-ce que TOUTES les requetes permettant un affichage commencent par SELECT ?
je pose cette question car je permet a des utilisateurs de afire des requetes de leurs choix dans une base via un champ input, mais je ne veux leur laisser la possibilité que d'afficher des informations sans poouvoir apporter quelques modifications que ce soit sur le données.
Netsupra
PS : je pourrais aussi refuser toutes requetes contennat un delete ou un edit plutot que de n'autoriser que les requetes commencant par select

Oui, on ne peut utiliser que SELECT pour récupérer des données.

Mais ce n'est pas du tout prudent comme idée...

Gare à la saisie de requête libre pour l'utilisateur même en supposant que tu imposes le début de la requête "SELECT" !!!

En effet il suffit de compléter la requête comme ceci :
Le point-virgule se place à la fin de chaque requête et permet d'en commencer une autre...

Comme Sedril te l'a indiqué, c'est assez dangereux: Prends le temps de jeter un coup d'oeil à propos de l'Sql injection (google est ton amis )
Il y a aussi la possibilité d'uiliser un utilisateur avec des droits réduits pour se connecter sur la base de donnée, pour toutes les pages qui ne font que des lectures dans la base de données.

Comme Sedril te l'a indiqué, c'est assez dangereux: Prends le temps de jeter un coup d'oeil à propos de l'Sql injection (google est ton amis )
Il y a aussi la possibilité d'uiliser un utilisateur avec des droits réduits pour se connecter sur la base de donnée, pour toutes les pages qui ne font que des lectures dans la base de données.

Ou sinon tu crées un nouvel utilisateur sur ton serveur avec des droits réduits mais il faut avoir accès à l'adminisatration de son serveur…

Ou sinon tu crées un nouvel utilisateur sur ton serveur avec des droits réduits mais il faut avoir accès à l'adminisatration de son serveur…

C'est un peu ce que j'avais écrit, non ??

Ou sinon tu crées un nouvel utilisateur sur ton serveur avec des droits réduits mais il faut avoir accès à l'adminisatration de son serveur…

C'est un peu ce que j'avais écrit, non ??

euh…

Ok merci.
Pour iclo, je connais bien les problemes d'SQL Injection (en tant que webmaster, vaut mieux ) mais j'essaye de trouver un solution permettant de laisser tous les droits de lecture a l'utilisateuir.
Que pensez vous tout betement d'uinterdire les requetes qui contiennt des UPDATE ou DELETE ?
Netsupra

Que pensez vous tout betement d'uinterdire les requetes qui contiennt des UPDATE ou DELETE ?

La suggestion d'avoir un utilisateur autorisé uniquement pour réaliser des SELECT, allait dans ce sens.
L'avantage c'est au niveau de la base de donnée que l'interdiction est faite, et pas dans le code php.

La suggestion d'avoir un utilisateur autorisé uniquement pour réaliser des SELECT, allait dans ce sens.
L'avantage c'est au niveau de la base de donnée que l'interdiction est faite, et pas dans le code php.

Oui et dans ce cas, c'est vraiment mais vraiment imparable, si la requète DELETE est interdite, alors le serveur SQL n'acceptera jamais de faire une seule suppression même si elle est habilement dissimulée dans un SELECT.

Sinon, si tu cherches toujours à le faire en PHP, une solution serait à la rigueur de proposer de choisir par exemple :
-Les champs à sélectionner (nom de la table et nom du champ)
-Les tables à choisir (avec une option pour l'inclure par un JOIN avec des conditions)
-Les conditions (fonction de comparaison, et arguments, le tout en permettant de choisir entre chaque condition l'opérateur logique)
-La limite
-L'ordre
Et à la fin tu regroupes tout. Le principe étant que plus tu divises la requète, plus tu brides l'utilisateur (si tu ne réimplémentes pas toutes les fonctionnalités du serveur), mais plus tu te permets de vérifier de manière sûre et facile la validité de la requète. Bref, il faut que tu fasses un choix dans les fonctionnalités pour savoir lesquelles sont non souhaitées, lesquelles sont souhaitables, et lesquelles sont indispensables (est il nécessaire de pouvoir faire des sous-requètes, des triggers, des tables temporaires, des JOIN, des GROUP BY, …) , pour ensuite pouvoir faire le meilleur compromis entre la sécurité souhaitée, la facilité d'implémentation, et les fonctionnalités, mais tout ce travail, c'est à toi de le faire.

Ok, merci pour tout ces elements. Le rpbleme n'est pas les competences mais la modelisation du script du point de vue securité. Avec tout ces elements, j'ai deja de quoi faire.
Merci a vous pour vos reponses.
Netsupra