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

Hello,

C'est sympa mais je crois qu'il faut revoir l'algo qui calcule le montant des propositions du banquier.
2 exemples assez étranges qui m'est arrivé :
    - je tire 3 boites et le banquier me propose direct 70000€ (c'est pas trop le cas en général)
    - il me reste 2 boites / une à 0.01€ et l'autre à 100€ (oui je suis pas chanceux :p) et le banquier me propose 1000€ ! Hum ? Le banquier n'est plus un chacal :)

Y'a plus qu'à mettre les musiques à la con de l'émission et ca sera du bonheur.

floflotz

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  !

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

Hello

Ca a l'air interessant mais t'aurais pu mettre un jar ou un batch histoire de pouvoir compiler/lancer ton appli en 2 secondes. (et oui, il faut penser aux fainéants ;-)).

+

floflotz

hello

je n'ai aucun carré rouge nulle part ! et meme avec sensibilité à 1 ca ne s'enregistre pas (avec la case cochée bien sur !).

Ca avait l'air intéressant mais chez moi ca ne marche pas !

Enfin aucune image ne s'enregistre malgré différents réglages.

J'y connais pas grand chose en delphi pour savoir ce qui coince. Dommage !

hello

sympa la source mais le bug est aussi chiant parce que quand la boule sort du parcours, impossible d'y retourner !
félicitations tout de même !

floflotz

>> Merci pour l'info,
>> En fait j'ai trouvé : le parametre "session.save_path" dans php.ini >> positionné à une mauvaise valeur (chemin inexistant)

>> Merci

la solution a été donné !!!!
le débat est clos ! chacun pense ce qu'il veut est voila !

désolé abarthes mais t'as pas du suivre le fil de la conversation !!!
pour certains cas, je suis d'accord avec toi mais dans le cas ici, bernard74 a fait n'importe quoi malgré les multiples avertissements qui sont affichés quand tu postes une source !!!
notre devoir est de lui signaler son erreur ! Certes nous aurions pu le faire avec un peu plus de tacte, mais il arrive un moment où tu satures !
Y'en a marre des mecs qui font n'importe quoi, qui prennent pas le temps de lire ce qu'on leur dit et ceux qui prennent pas le temps de faire une tite recherche sur le forum avant de poster un message qui est revenu 150000 fois ! Ok ca peut arriver à tout le monde mais y'a un moment où ca soule !!!!