Générer une requete sql avec javascript
Soyez le premier à donner votre avis sur cette source.
Vue 49 514 fois - Téléchargée 1 276 fois
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:
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.
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 / Exemple :
<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.
Codes Sources
A voir également
- Javascript sql
- Sql javascript - Meilleures réponses
- Requete sql javascript - Meilleures réponses
- [Javascript] & ✓ - Forum - Javascript / DHTML
- Problème javascript + liste déroulante + requête SQL ✓ - Forum - Javascript / DHTML
- Gérer un agenda en Javascript en récupérant des dates SQL ✓ - Forum - Javascript / DHTML
- Requete sql en dans une function javascript ✓ - Forum - Javascript / DHTML
- Requête my sql et javascript ✓ - Forum - Javascript / DHTML
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 !
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.