Reprise du message précédent :

C'est pour faire un peu de traitement, genre pour un cas en situation réel. Et on voit que ce qui bouffe tout là-dedans, c'est la connexion... donc faut la dégager, vu qu'elle sert à rien

>Je viens de te prouver que c'était fiable
non tu viens de prouver que ça "marchait".
Passe ta base de données dans un charset étrange, avec une config à la con, et tu vas être baisé par stripslashes.
Ta méthode n'a donc aucune portabilité.  
(ouais j'ai craqué, pas pu m'empêcher de répondre )

Lol quoi, quand ça t'arrange, ça diminue les perfs et quand ça t'arrange pas, spa grave qu'on perde des perfs. relol quoi.
 

C'est pour ça que j'ai bien dit que ce n'était valable que si connexion (ce n'est pas possible de toutes façons sans).
Il est évident que dans un autre cas sans connexion, j'improviserais, mais en fait, ça ne m'ait jamais arrivé.

Nan Quand on teste un truc comme ça, faut voir dans un cas réel.
 
C'est comme la différence entre print et echo, ou single-quote vs. double-quote. Je me suis rendu compte y'a trois jours que finalement ça changeait strictement rien, vu qu'on n'en fait pas 10 000, mais une vingtaine au plus. Et juste pour 20, bah la différence de perfs est totalement minime...

Cela dit, chez moi, c'est pas kifkif, c'est 25% plus vite pour le mres que pour le str_replace, en moyenne, sur un WAMP et sur un LAMP.

Ouais, mais pour 50 000 itérations... Pour seulement 20, la différence se fera au niveau de la connexion supplémentaire nécessaire pour le cas mres

> j'improviserais
Et pourquoi improviser ? pourquoi ne pas utiliser une méthode réutilisable dans n'importe quel contexte, et portable avec n'importe quel base ?
 
Le jour où ton boss il te dit de passer a postGre, tu fais quoi avec tes mres ? oO
 
Et comment séparer la logique métier du SQL, si t'as des mres partout ?
 
Au-delà de ça, je capte vraiment pas comment on peut faire un site où une connexion mysql est systématiquement requise, et pendant toute la durée de tous les scripts.

Vu que mon mres est dans une fonction $toto=mres($_POST['toto']);, je n'aurais qu'à modifier ma fonction mres.
 

ça ok, et pour le :  
Et comment séparer la logique métier du SQL, si t'as des mres partout ?
et pour le :  
et portable avec n'importe quel base ? (n'oublie pas qu'il suffit de changer le charset de ta base pour que ça merde

Je n'ai pas des mres partout, au début de mes script, j'ai juste des lignes pour "sécuriser" ce que peut entrer l'utilisateur, faut pas exagérer les cas extrême non plus.
Si j'ai plus de 3 données à récupérer des utilisateurs, c'est que de toutes façons, c'est surement destiné à une bdd et là le mres est obligatoire.

ça change rien, tu merde du métier avec du SQL. Et tu empêches la portabilité sur une base mysql "exotique"
 
edit : tiens regarde la doc php

Donc en plus de dépendre de la base mysql, tu échappes des choses qui n'ont pas lieu d'être échappées, et non annulées par stripslashes.
 
Et je me répète mais :  
>Au-delà de ça, je capte vraiment pas comment on peut faire un site où une connexion mysql est systématiquement requise, et pendant toute la durée de tous les scripts.

Je n'empêche rien du tout, ça me permet de regrouper les données utilisateurs diverses et les données utilisateurs destinés à une bdd en début de script sans m'intéroger de leur destination, c'est tout.
 
Alors toi j'imagine, tu récupères 5 données utilisateurs en début de script, tu te poses la question pour chaque données : Euh... Alors celui là, je vais lui mettre un STR, et celui là... euh, ha, il va dans la bdd, bon, un mres, et celui là, euh, je sais plus, je vais voir... ha oui okey, donc str_replace... celui là... euh, mres...
 
Bref, moi, tous les $_GET, $_POST, $_COOKIES, etc. ensemble, hop, mres à tout comme ça si je modifie mon script et que finalement une donnée au départ n'était pas prévue pour aller dans une BDD mais que finalement elle y va, bah je n'ai même pas à vérifier qu'elle a été sécurisé avant.

Si si, essayes.
 

bah non, je fais absolument rien sur les input utilisateurs :  
dans ma couche mysql, y a systématiquement un mres sur les variables.
Le seul cas  où php nécessite un filtrage des input, c'est pour l'utilisation dans des headers (et c'est même plus le cas aujourd'hui). Bref, aucune hésitation à avoir.

Dans les headers, on met des $_GET et des $_POST et des $_SESSION, etc.    

bah oui, donc le seul et unique cas où j'ai une question à me poser, c'est si j'utilise un input dans un header, et la faille a été corrigé, donc en fait ... j'ai rien à faire

Et ben ouais, c'est comme ça qu'il faut faire Tu ne sais justement pas où vont atterir les données, donc vaut mieux les laisser en début de script non escapées.
 
Ensuite suivant là où tu envoie, bah tu escape : mres pour mysql, htmlspecialchars pour html, urlencode pour liens, etc. Si tu mres cash au départ, bah va falloir dé-mresser (ouch), et hop perte de performance

 
J'ai plusieurs site en prod , et sur trois d'entre eu , la seule page qui ne contient pas d'appel aux BDD est la page avec le formulaire demandant login et mdp
chaque page contient des données personnalisée, des comptage, en trop grande quantite pour le mettre en cahce ( ou alors il faut le mettre en cahe dans une bdd   )

pst, vous voudriez pas retourner vous battre dans blabla@web ?

Parce que quelqu'un a corrigé la faille pour toi.
 

Perso, je préfère sécurisé avant et bosser après sur le reste, c'est pour ça que je disais que ma méthode était une méthode comme une autre, on l'adopte ou pas, ràf, mais qu'on dise que c'est mal, non, concrètement, elle est efficace, que demander de plus ?
 

Bah non, on blablate pas là et on se bat pas.
 

Ouais, mais tu sécurises trop top, et tu ne sécurise que pour un cas spécial...  Sécuriser, c'est sécuriser pour un truc particulier. Y'a parfois aussi où la variable ne doit pas être sécuriée : Si jamais par exemple t'as besoin de faire une comparaison ou un truc comme ça, y'a des risques de foirage...

>concrètement, elle est efficace
une solution qui dépend de la config de la base MySQL, et qui fait des trucs qui sont pas utiles en fonction du script, j'appelle pas ça une solution efficace
Bref, accepte juste que je puisse être opposé à ta solution
 
>Y'a parfois aussi où la variable ne doit pas être sécuriée : Si jamais par exemple t'as besoin de faire une comparaison ou un truc comme ça, y'a des risques de foirage...
+1
Là je bosse sur un analyseur de log, bah si les lignes du log étaient passé au mres, ça bugguerait, et ça ramerait. (fichiers de plusieurs Mo analysé en PHP)
 
>chaque page contient des données personnalisée, des comptage, en trop grande quantite pour le mettre en cahce ( ou alors il faut le mettre en cahe dans une bdd   )
données qui peuvent soit être mises en session, soit demandées en début de script avec fermeture de la connexion derrière ...
J'ai déjà mis en session un objet en contenant 100 000 autres (oui, vraiment), ça ramait grave moins que de réinterroger la bdd ... alors me dis pas qu'on peut pas les mettre en session

Opposé à l'utiliser oui, tu fais ce que tu veux, dire qu'elle est mauvaise, tu n'as aucun exemple concret pour le prouver donc bon, elle reste valable tant qu'il y a une connexion MySQL.
 

Tes logs ne sont pas rentrés pas l'utilisateur, donc je ne mres pas. Tu piges pas tout j'ai l'impression.    
 

Pourquoi, tes données utilisateurs, tu les récupères en fin de script toi ?
 

Je préfère un petit risque de foirage qu'un gros risque de piratage.
Et vu comment ça bosse intensivement, je n'ai jusque là jamais eu de problème, je ne parle pas de théorique, le site de ma femme, c'est un million de page vue par an et une multitude d'entrée utilisateur, donc bon, comme j'ai dit plus haut, c'est une méthode qui a fait ses preuves.  

Mais y'a plein d'autres méthodes qui évitent le piratage, et qui reposent pas sur un MRES automatique... Genre là j'me fais 2-3 scripts pour Mysql, avec genre gestion des requêtes paramétrées, ce qui m'évitent même d'avoir à MRESser manuellement, tout est fait tout seul

 
je travaille sur des site avec pas mal d'utilisateur en // , donc il est hors de question de surcharger les sessions  
 
en plus, tu pars du principe que les données sont les mêmes d'une page à l'autre, ce qui n'est pas le cas  
docn a mons de tout calculer lors du login , c'est impossible  
 
chaque site à des contraintes differentes, perso , sur certains ds sites que j'ai fait, un objet de 1000 autres dans chaque sessions, et je suis bon pour racheter des disques durs

>tu n'as aucun exemple concret pour le prouver donc bon
jt'en ai donné des tas mais bon, si tu veux pas les lire ...
 
>Tes logs ne sont pas rentrés pas l'utilisateur
bah si justement ... log upload par l'utilisateur pour que les infos soient analysées et rentrées en bdd ... je mres que dans les requetes bdd, pas pendant la phase d'analyse (qui est longue et ne doit pas bouffer une connexion pendant tout ce temps), sinon ça planterait.
 
>Pourquoi, tes données utilisateurs, tu les récupères en fin de script toi ?  
rien à voir avec ce que j'ai dis : je dis que y a des pages où y a pas besoin de mres ET pas besoin de connexions à la base. Toi tu me réponds que sisi, une connexion à la base tu en as forcément besoin à chaque page. Moi je te dis qu'il y a plein de pages où les infos sont récupérée en début de script, et tu peux fermer la connexion pour le reste du script (puisque c'est pas une page où tu insère en bdd les données utilisateurs)
 
>chaque site à des contraintes differentes, perso , sur certains ds sites que j'ai fait, un objet de 1000 autres dans chaque sessions, et je suis bon pour racheter des disques durs
t'as pas tort, faudrait que je revoie ça. Mais bon encore une fois, t'as plein de pages où tu récup les infos dans la bdd au début et basta.

Non non, tu n'as rien donné comme exemple concret, juste des suppositions de situation qui pourraient éventuellement arrivés.
Du genre de "mres ça rame trop". Et résultat, je vous ai prouvé concrètement le contraire.

Non, t'as prouvé que c'était la même chose, et qu'on peut utiliser l'un ou l'autre sans grande différence (sauf avec 50 000 itération). Y'en a juste un qui a besoin d'une connection à la base, et pas l'autre

Bah c'est ce que j'arrête pas de dire, par contre, non, retest, sur 50 000 itérations, je vais 25% plus vite avec un mres. Bon, à l'échelle d'un script, c'est du pipeau, je sais bien, mais comme c'était votre argument de départ qui se retourne contre vous, je le souligne.    

Hum... tu ne dois pas connaître "thor" et "privoxy".
En attendant j'ai la preuve que l'IP qui est vue depuis un site cible n'est pas l'IP que m'a attribué mon FAI...

Ah non moi j'ai rien dit, j'ai juste parlé de la connexion en plus On a dû mal se comprendre

Justement, je sais très bien comment fonctionne les proxys et je sais très bien analyser les emails automatiques que je reçois.
Enfin, si tu veux jouer à ça, la prochaine attaque, je porte plainte contre X et un juge ira demander les logs à HFR par exemple. Je jouais les caïds comme toi jusqu'à ce que je me retrouve devant un commissaire la queue entre les jambes (enfin, normal jusque là, mais toute petite, toute toute petite).
 
Une règle de base des vrais hackers, c'est de fermer sa gueule sur ce qu'on fait et de ne jamais en parler sur un forum, qui plus est ouvert au public.

> tu n'as rien donné comme exemple concret
C'est pas concret de merder son métier avec du SQL ?
C'est pas concret de dépendre de la configuration d'une bdd, en réduisant la portabilité ?
C'est pas concret d'être dépendant d'une connexion et de devoir "improviser" selon tes propres termes dès que les contraintes changent ?
C'est pas concret qu'il y ait moultes cas où PHP n'a aucun besoin de (voire même ne doit pas) protéger les input ?
 
Ha bah oui alors, j'ai rien dis de concret  

Non
 

Non, j'allais citer les phrases une par une, mais non, tout ça c'est des suppositions.  

où tu vois une supposition dans le merdage de la logique métier ? tu mets du SQL dans la logique métier, la concrétisation c'est ton code hein.
 
Où tu vois une supposition dans le fait que mres dépende de la bdd ?

 
Où c'est pas concret que PHP n'a aucun besoin de protéger tous les inputs ? Tu dois coder bizarrement si tu ne penses pas que ça soit concret.
 
Enfin bon tu sais quoi ? t'as raison stu veux

Ouai j'ai raison, je le sais.

un exemple de Unix Code execution ....
http://photohainaut.no-ip.info/ind [...] retenir=on

Ha ouai, c'est méchant ça.

Okay ! Je viens de la piger Je connaissais absolument pas
 
On peut aussi l'écrire comme ça :
http://photohainaut.no-ip.info/ind [...] retenir=on
 
Le truc spécial étant : (sans url encodage)

 
 
Si j'ai bien compris, il a lié l'authentification à son serveur, c'est bien ça ? Et il lance une commande pour voir si l'utilisateur existe. Et on peut justement se greffer à la commande (via le point-virgule qui permet d'en lancer une nouvelle). Donc normalement si je ne me trompe pas, faudrait faire un escapeshellarg de $_POST['mylogin']...