GÉNÉRER UNE REQUETE SQL AVEC JAVASCRIPT
floflotz
Messages postés
240
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
6 janvier 2006
-
19 juil. 2005 à 00:06
centy2010 Messages postés 4 Date d'inscription jeudi 20 mai 2010 Statut Membre Dernière intervention 30 juin 2010 - 30 juin 2010 à 00:02
centy2010 Messages postés 4 Date d'inscription jeudi 20 mai 2010 Statut Membre Dernière intervention 30 juin 2010 - 30 juin 2010 à 00:02
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/32766-generer-une-requete-sql-avec-javascript
https://codes-sources.commentcamarche.net/source/32766-generer-une-requete-sql-avec-javascript
30 juin 2010 à 00:02
on peut aussi limiter le GRANT aux champs de la table que l'on permet de selectionner.
Enfin j'essaye pas de faire approuver cette façon de générer le Statement.
Juste de considérer la faisabilité dans un environnement sécurisé.
29 juin 2010 à 19:50
Il faut le remettre dans le contexte de l'époque, où j'étais un jeune étudiant fraichement sorti de l'école, qui s'essayais à toutes les technologies et avec une grande envie de bien faire.
Sans rentrer dans les détails techniques, je déconseille ce code, pour les raisons suivantes :
- le code javascript s'exécute du côté du client
- n'importe qui peut lire son contenu en affichant juste le code source de la page
- les requêtes sql écrites donnent des informations sur la structure de la base données (nom de table)
- les requêtes peuvent être modifiées par n'importe qui car pour récupérer ces données et les traiter sur le formulaire, on peut manipuler la valeur du paramètres "action" sur une page tierce
- la gestion des privilèges n'est souvent pas du ressort du développeur (et souvent l'administrateur de la base de données donne accès en insert,update, et très souvent delete)
Sur le plan syntaxique ce code est utile pour ceux qui veulent savoir comment :
- tester des chaines de caractères,
- concaténer des données récupérer des valeurs de champs de formulaires.
Mais sur le principe décrit ci-haut(construction d'une requête sql), il est mauvais.
Aussi, il est très difficile d'utiliser javascript pour interagir avec une base de données directement sans passer par un serveur d'application (apache, IIS, etc ...)
Et tous ces serveurs disposent de moteur de script (php, asp, asp.net) qui peuvent construire des requêtes sans que cela ne s'exécute côté client.
Et je conseille vivement de manipuler les requêtes du côté du serveur, ou au mieux de le gérer dans la base de données à l'aide de procédures stockées ou packages.
29 juin 2010 à 00:31
Quel plaisir de voir que des posts vieux comme le monde vivent encore :)
Ca fait bien longtemps que j'avais pas mis les pieds par ici et à force d'être harcelé de mails, ma curiosité m'a poussé à venir voir ce qui déchainait autant les passions sur ce post.
Je suis à l'origine du mot "dangereux". Le but n'est pas de remettre de l'huile sur le feu mais je pense qu'il faut insister sur quelques détails. Je ne suis pas là pour faire des querelles de voisinage, je n'ai rien à prouver à personne et mon message sera courtois.
Si on prend la chose comme un "proof of concept", en effet ça peut-être intéressant .... quoique très limité quand même :D
La principale chose à retenir, et la base de mon message il y a 5 ans, c'est que beaucoup de débutants perdus tombent sur ce genre de code. Certains d'ailleurs dans les coms le trouvent "merveilleux" ou encore "très utile". Autant dire une aberration venant personnes inexpérimentés ! Et c'est là où ça en devient dangereux. Un débutant n'aura pas idée de protéger l'accès par un utilisateur en lecture seule. Et quand bien même, je n'adhère absolument pas sur le fait que l'on puisse considérer ce code comme utilisable ... encore plus sous prétexte que "ça marche" !
Même avec un user en read only, un pirate pourrait en effet récupérer plus de champs que nécessaire sur la table par un bon select *...
Et tel quel par un copier-coller de source sans comprendre (comme ça arrive malheureusement trop souvent), ça représenterait une très très grosse faille de sécurité.
Et c'est que là qu'il est primordial que les gens qui lisent ce code se rendent compte que c'est une vraie passoire sur le plan sécurité. Beaucoup de personnes ici ne savent même pas que la notion d'utilisateurs existe dans MySQL.
La personne qui a posté le source aurait du indiqué cet avertissement ou les précautions d'usage ! C'est donc à nous, personnes expérimentés de la communauté, de les alerter sur les risques qu'ils encourent.
Au final pour clôturer :
Ce genre de code est vivement déconseillé pour un site web en production. C'est plutôt un bon exemple d'une mauvaise idée de construction de requêtes côté client.
Si vous souhaitez l'utiliser, pensez à :
- créer un utilisateur en lecture seule pour éviter une altération des données (http://dev.mysql.com/doc/refman/5.0/fr/user-account-management.html)
- donner les droits d'accès uniquement sur des vues (pour lesquelles vous aurez au préalable restreint la quantité de données, c'est-à-dire de colonnes, accessibles dans la requête)
Sur ce, bonne continuation à tous
28 juin 2010 à 23:09
Et pour tout te dire et je continue à le dire, son code n'a rien de dangereux.
Tout simplement parceque sa requête SELECT peut être faite via un utilisateur readonly.
Même si c'est pas une méthode habituelle de générer son SQL statement dans le Javascript, son code n'a rien de dangereux en soit.
Et j'avoue que c'est ton commentaire sur l'algorithme qui m'a fait tiquer parce que je trouvais ça tout à fait inutile. Et comme tu peux t'en rendre compte, le niveau est indiqué en haut de la page.
Maintenant c'est sur que celà n'est pas recommandé mais du point de vue CONCEPT, comme tu dis, Je ne suis justement pas de l'avis général de dire que son code est dangereux.
27 juin 2010 à 23:28
"As-tu déjà travailler correctement avec du SQL ou du MySQL ?"
Tu veux dire quoi au travers de ta phrase ? Procédure stocké, déclencheur, différents type de jointures, gestion des schémas utilisateur ou des structure de données ? La notion de "correctement" m'a quitté après ma "licence".
Ensuite sous MySQL je t'avoue ne jamais avoir géré de privilège, je n'utilise que MySQL pour du développement WEB et toutes mes requêtes sont exécuté par mon serveur. Lorsque j'utilise une Base de données pour application partagée j'opte pour un SGBDR plus développé et mieux optimisé.
Maintenant sur Oracle sans problème et même de manière récurrente ceci dis, la gestion des privilège ne se limite pas à cela un grant ou un revoke pour moi Et la gestion des procédures stockés est apparu tardivement et est encore très mal géré par MySQL (=>Temps d'exécution)
Quant au début de ma phrase, j'imagine que tu as du "tiquer" sur le mot algorithme qui comporte plus de 3syllabes. Donc Je vais te dire franchement une source qui parcours un formulaire pour concaténer une chaine, pour enfin la mettre dans un champ de formulaire. Je ne trouve pas ça exceptionnel (ça doit être mon manque d'expérience hein?). D'ou une déduction du fait que l'auteur à mis cette source pour le CONCEPT et non pour l'algorithme lui même !
Et effectivement ne perds pas de temps on est que des "newbie et on ne rox pas notre life tu kiff ? ou t'a le sum ?"
Sur ce Bonne journée à tous !
27 juin 2010 à 17:21
As-tu déjà travailler correctement avec du SQL ou du MySQL ?
Getion des privilèges limités ??? As-tu déjà utilisé un statement "GRANT", "REVOKE" ou "SHOW GRANT" ???
Et puis simplement en commençant ta phrase tu montres déjà le peu d'expérience que tu as. Enfin, je répondrai plus sur javascriptfr... ça m'a l'air d'être une bonne bande de newbies qui font des commentaires ahurissants à tord et à travers sans même avoir de notions SQL.
24 juin 2010 à 16:10
Sur le plan algorithmique rien de bien intérréssant, mais je suis de l'avis global ce genre de gestion est bien trop dangeureuse.
Pour répondre à Centy2010 ! Une gestion des privilège peut palier aux problèmes!!! ceci dis la plupart des sites internet tourne sous MySQL... et la gestion des privilège est assez limité.
16 juin 2010 à 10:39
20 mai 2010 à 13:13
Le code n'a rien de dangereux. Lorsque FLOFLOTZ parle de tentatives de destruction d'une base de données SQL, il devrait comprendre qu'une bonne gestion empêche justement ce genre de tentative. (Gestion des privilèges)
10 nov. 2009 à 18:47
Je ne me souviens plus comment j'ai mis en place ce script (qui n'est qu'un extrait ici car la version complete est plus complexe) mais il est en place depuis plus de 3ans et il n'y a jamais eu le moindre probleme de sécurité.
ps: merci omny pour ta remarque fort constructive, j'apprécie tout particulièrement le "code bidon" et tes qualités de rédacteur
10 nov. 2009 à 14:36
19 août 2007 à 16:51
pour le post un java script de 2 ligne casse ça avec l'objet de XMLHttpRequest ca prend pas de temp
La bonne chose a faire c'est faire une page PHP qui elle parle avec la BD et ton client l'intéroge pour avoir les information qui t'intéresse. Sur la page PHP tu fait la sécurité en controlant toute entré malsaine.
En aucun cas il faut donner un accet au client de la BD
en espérent t'avoir donner des idée pour ta prochaine version ;)
24 janv. 2006 à 17:11
<script>
function calcul () {
var val1=0;
var val2=0;
var val3=0;
if(document.caddie.select1.value != "Composantes"){
val1=document.caddie.select1.value;
caddie.Total.value=val1;
}
if(document.caddie.select2.value != "Légumes"){
val2=document.caddie.select2.value;
caddie.Total2.value=val2;
}
var totaux = val1 - val2 - val3;
caddie.totaux.value = totaux;
}
</script>
<FORM name="caddie">
<SELECT name="select1" onchange="calcul(this)">
<OPTION SELECTED>Composantes
<OPTION VALUE="Potages">Potages
<OPTION VALUE="Entrée froides">Entrées froides
<OPTION VALUE="Entrées chaudes">Entrées chaudes
</SELECT>
<SELECT name="select2" onchange="calcul(this)">
<OPTION SELECTED>Légumes
<OPTION VALUE=1>Artichaud
<OPTION VALUE=2>Asperge
<OPTION VALUE=3>Auberge
</SELECT>
Total:
</FORM>
cest ptet pas tres propre mais ca marche...
bon codage a tous :)
11 août 2005 à 16:18
La génération de requête SQL est à faire coté serveur. Dans une architecture web, le client ne doit jamais manipuler de requête SQL! Il faut bien comprendre ce qui se passe du coté client et du coté serveur.
Bref, ce code est une abbération, une faille de sécurité énorme, à ne JAMAIS utiliser.
(désolé pour l'auteur)
19 juil. 2005 à 20:28
19 juil. 2005 à 16:50
Rendez-vous peut être sur les codes sources PHP.
19 juil. 2005 à 13:08
sur le net, c'est pas sécurisé, mais en local, ça peut être interessant...
19 juil. 2005 à 12:05
Bien que tu utilise la méthode POST, on peut envoyer à ta page ce que l'on veut par deux moyens :
- utiliser un petit code indépendant en Javascript qui ferait uniquement le travail de validation par exemple 'document.form1.UneRequete.value="delete * FROM annuaireibs"; document.form1.submit();'
- faire un petit programme exécutable qui envoie une requête en POST à ta page et qui serait "delete * FROM annuairebis" !
Dans les 2 cas le code qui exécute ta requête coté serveur croirait que l'utilisateur a correctement remplit ses champs ! Ce serait désastreux pour ton site qui tomberait en 5 minutes.
Alors je suis d'accord que toutes les folies sont permises mais dans ce cas, précise que ce code est dangereux donc à éviter. C'est surtout dans l'intérêt des débutants qui pourrait voir ici une mauvaise méthode !
19 juil. 2005 à 10:00
L'intérêt vient du fait que tous les champs de saisie sont optionnels et il faut bien construire la requête qu'il faut avant de l'envoyer vers la page d'exécution, bioensur, tout cela peut être fait côté serveur, mais une application javascript est quand même intéressante à voir. (On est sur www.javascriptfr.com quand même, toutes les folies sont permises)
19 juil. 2005 à 00:06
En plus, il y a un gros problème de sécurité car on peut envoyer la requete que l'on veut à ton serveur (comme un 'delete *' par exemple).