begin process at 2012 02 12 10:53:53
  Trouver un code source :
 
dans
 
[ Dernières recherches ]
Accueil > 

Code

 > 

Trucs & Astuces

 > GÉNÉRER UNE REQUETE SQL AVEC JAVASCRIPT

GÉNÉRER UNE REQUETE SQL AVEC JAVASCRIPT


 Information sur la source

Note :
5 / 10 - par 7 personnes
5,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Trucs & Astuces Niveau :Débutant Date de création :18/07/2005 Vu / téléchargé :36 458 / 824
Auteur : rahou

Ecrire un message privé
Site perso
Commentaire sur cette source (20)
Ajouter un commentaire et/ou une note

 Description

Il vous peut être arrivé de vouloir envoyer des informations à partir d'un formulaire dont tous les champs de saisie sont optionnels. Et par la suite de vous afficher sur une autre page le résultat d'une requête dont les critères de recherche proviennent de la page précédente.
Vous devez avant tout vérifier la saisie correcte des données et ensuite générer la requête adéquate qui sera exécuter dans la page suivante.
C'est ce que j'ai essayé de faire et que vous pourrez tester sur l'adresse suivante: www.ibs.sn/annuaire/.
Le code javascript de saisie vérification de la saisie du formulaire et de génération de la requête sql est le suivant:

Source

  • <script language="javascript">
  • function EnregistrerFiche()
  • {
  • var saisie=0;
  • var requete;
  • if (document.form1.Nom.value!='')
  • {
  • saisie++;
  • requete="Nom='"+document.form1.Nom.value+"'";
  • }
  • if (document.form1.Prenom.value!='')
  • {
  • if (saisie>0)
  • {
  • saisie++;
  • requete=requete + " AND Prenom='"+document.form1.Prenom.value+"'";
  • }
  • else
  • {
  • saisie++;
  • requete="Prenom='"+document.form1.Prenom.value+"'";
  • }
  • }
  • if (document.form1.Profession.value!='')
  • {
  • if (saisie>0)
  • {
  • saisie++;
  • requete=requete+ " AND Profession='"+document.form1.Profession.value+"'";
  • }
  • else
  • {
  • saisie++;
  • requete="Profession='"+document.form1.Profession.value+"'";
  • }
  • }
  • if (document.form1.AnneeEntree.value!='Choisir une Annee')
  • {
  • if (saisie>0)
  • {
  • saisie++;
  • requete=requete+ " AND AnneeEntree='"+document.form1.AnneeEntree.value+"'";
  • }
  • else
  • {
  • saisie++;
  • requete="AnneeEntree='"+document.form1.AnneeEntree.value+"'";
  • }
  • }
  • if (document.form1.SecteurActivite.value!='--Chosir un secteur--')
  • {
  • if (saisie>0)
  • {
  • saisie++;
  • requete=requete+ " AND SecteurActivite='"+document.form1.SecteurActivite.value+"'";
  • }
  • else
  • {
  • saisie++;
  • requete="SecteurActivite='"+document.form1.SecteurActivite.value+"'";
  • }
  • }
  • if (saisie>0)
  • {
  • document.form1.UneRequete.value="SELECT * FROM annuaireibs WHERE "+requete;
  • document.form1.submit();
  • }
  • else
  • alert("Champs non saisis");
  • }
  • </script>
<script language="javascript">
function EnregistrerFiche()
{
	var saisie=0;
	var requete;
	if (document.form1.Nom.value!='')
	{	
		saisie++;
		requete="Nom='"+document.form1.Nom.value+"'";
	}
	
	if (document.form1.Prenom.value!='')
	{
		if (saisie>0)
		{	
			saisie++;
			requete=requete + " AND Prenom='"+document.form1.Prenom.value+"'";
		}
		else
		{	
			saisie++;
			requete="Prenom='"+document.form1.Prenom.value+"'";
		}
	}
	
	if (document.form1.Profession.value!='')
	{
		if (saisie>0)
			{
				saisie++;
				requete=requete+ " AND Profession='"+document.form1.Profession.value+"'";
			}
		else
			{
				saisie++;
				requete="Profession='"+document.form1.Profession.value+"'";
			}
	}
	
	if (document.form1.AnneeEntree.value!='Choisir une Annee')
	{
		if (saisie>0)
			{
				saisie++;
				requete=requete+ " AND AnneeEntree='"+document.form1.AnneeEntree.value+"'";
			}
		else
			{
				saisie++;
				requete="AnneeEntree='"+document.form1.AnneeEntree.value+"'";
			}
	}
	
	if (document.form1.SecteurActivite.value!='--Chosir un secteur--')
	{
		if (saisie>0)
			{
				saisie++;
				requete=requete+ " AND SecteurActivite='"+document.form1.SecteurActivite.value+"'";
			}
		else
			{
				saisie++;
				requete="SecteurActivite='"+document.form1.SecteurActivite.value+"'";
			}
	}
	
	if (saisie>0)
	{
		document.form1.UneRequete.value="SELECT * FROM annuaireibs WHERE "+requete;
		document.form1.submit();
	}
	else
		alert("Champs non saisis"); 
}
</script>

 Conclusion

En cliquant sur le bouton "Envoyer" du Formulaire de saisie dont le code est le suivant.
<input name="Bouton" type="button" id="Envoyer" onClick="EnregistrerFiche();" value="Recherche">,
la fonction "EnregistrerFiche()" est appelée, cette fonction teste l'ensemble des champs de saisie et dispose du compteur "saisie" qui permet de savoir si un champ a été saisi oui non. Et au fur et à mesure que les champs sont marqués comme contenant des valeurs, une requête sql est générée et stockée dans le champs texte caché et nommé "UneRequete".
Le formulaire est ensuite envoyé avec la méthode POST.
La valeur contenue dans le paramétre "UneRequete" est récupérée par la page d'affichage des résultats, qui à son tour l'exécute.

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Sources du même auteur

VÉRIFIER DES CHAMPS DE SAISIES 'UN FORMULAIRE
Toutes les sources de rahou

 Sources de la même categorie

Source avec Zip Source avec une capture SUBDIVISER LE RÉSULTAT D'UNE RECHERCHE EN PAGES par kimmp
Source avec Zip TIMER : SETTIMEOUT & SETINTERVAL AMÉLIORÉS par jdmcreator
Source avec Zip Source avec une capture ONGLETS ET CHANGEMENT INSTANTANÉ DE LA LANGUE par william voirol
Source avec Zip Source avec une capture COPIER DU TEXTE par m22001111
Source avec Zip DIALOGUE ENTRE FENÊTRES MÈRE ET FILLE par william voirol
Toutes les sources de la catégorie Trucs & Astuces

Commentaires et avis

Commentaire de floflotz le 19/07/2005 00:06:51

Je ne vois pas du tout l'intérêt de construire ta reqête côté client alors que tu peux le faire côté serveur !!!

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).

Commentaire de rahou le 19/07/2005 10:00:20

la méthode d'envoie est POST, ce qui veut dire que la requête n'est pas visible côté client et ne peut en aucun cas être envoyé par une autre personne.
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)

Commentaire de floflotz le 19/07/2005 12:05:20

Certes toutes les folies sont permises mais ce code n'est pas un bon exemple pour la simple et bonne raison qu'elle est vraiment dangereuse !

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  !

Commentaire de coucou747 le 19/07/2005 13:08:29 administrateur CS

ou en telnet...

sur le net, c'est pas sécurisé, mais en local, ça peut être interessant...

Commentaire de rahou le 19/07/2005 16:50:36

Pour vous faire plaisir, je vais déposer une seconde version de ce code pour vous faire plaisir. Et cette version sera plus sécurisée.
Rendez-vous peut être sur les codes sources PHP.

Commentaire de coucou747 le 19/07/2005 20:28:24 administrateur CS

poste pas ta source en double non plus !

Commentaire de nicovmd le 11/08/2005 16:18:16

Avis à tous : n'utilisez JAMAIS un code comme celui-ci.
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)

Commentaire de decaPeter le 24/01/2006 17:11:17

et bien moi je trouve ton code merveilleux et il va m'etre tres utile car cest exactement ce que je cherchais a faire. bon ok moi je rajoute un script qui sert de compteur de réponse en temps réel... si vous voulez vous inspirer:

<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><body onload="calcul(this)">
<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>
<br>
<SELECT name="select2" onchange="calcul(this)">
<OPTION SELECTED>Légumes
<OPTION VALUE=1>Artichaud
<OPTION VALUE=2>Asperge
<OPTION VALUE=3>Auberge
</SELECT>
<br>
<br>Total:
<input type="text" name="totaux" value="1000" size="8" readonly>
<br>
<input type="submit" name="chercher" value="Rechercher">
</FORM>
</body>


cest ptet pas tres propre mais ca marche...

bon codage a tous :)

Commentaire de Mirtador le 19/08/2007 16:51:58

Bon je crain de devoir dire comme mes confrère plus haut. Ton site ce fait cracker extraimemant aisémant pour vue que tu connaisse un peut le code du site..., J'ai pas trop eu le temp de lire ton code, mais il n'y intervien aucune page PHP... Donc tu fait un appelle plus ou moin directe à ta BD... Le java script s'execute coter client, il est donc influenssable par l'utilisateur.

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 ;)

Commentaire de omny le 10/11/2009 14:36:21

c'est bien de vouloir fait tout avec javascript, mais si il y a un risque il faut le dire sans gène, ce n'est pas parcequ'on est sur www.javascript qu'on va accepté des codes bidons, alors dit moi comment crée une requête java-script sécurisante, seulement avec java script et SQL  coté serveur ?  merci

Commentaire de decaPeter le 10/11/2009 18:47:13

merci Mirtador pour tes remarques.
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

Commentaire de centy2010 le 20/05/2010 13:13:37

Je ne vois pas
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)

Commentaire de luque19 le 16/06/2010 10:39:08

merci pour ce code ca ma bien aide

Commentaire de TheWeasel47 le 24/06/2010 16:10:44

Salut à tous !
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é.

Commentaire de centy2010 le 27/06/2010 17:21:43

TheWeasel47, tu te rends bien compte que tu dis n'importe quoi ?
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.

Commentaire de TheWeasel47 le 27/06/2010 23:28:36

Bon alors première chose je n'ai pas à justifier de mon parcours professionnel avec toi.

"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 !

Commentaire de centy2010 le 28/06/2010 23:09:53

ce genre de chose oui :D

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.

Commentaire de floflotz le 29/06/2010 00:31:30

Bonjour tout le monde

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

Commentaire de rahou le 29/06/2010 19:50:00

Je constate que ce code que j'avais posté il y'a 5 ans nourri encore de vives commentaires.
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.

Commentaire de centy2010 le 30/06/2010 00:02:03

on peut imaginer que le pattern du statement SQL soit vérifié par la page de traitement.
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é.

 Ajouter un commentaire

Nos sponsors


Sondage...

Comparez les prix


Sony Ericsson XPERIA X10 (1 Go)
Entre 649€ et 649€

Visiter le guide achat

CalendriCode

Février 2012
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
272829    

Consulter la suite du CalendriCode
 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 1,825 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales
Outils Convertisseur VB/C# Snippets et scripts Outils en ligne La ToolBox
Communauté Programmation Photographie Technologie Newsgroups Emploi Forum Blogs
Guide d'achat Téléphonie mobile Image et son Informatique Bureautique Jeux vidéo
Logiciels Internet & Réseau Développement Market Android Jeux & Loisirs Graphisme Multimédia Sécurité Pilotes
Loisirs Cartes virtuelles Vidéos droles Jeux en ligne Géoguide AndroLib (Android Market)