Reprise du message précédent :

mauvais argument la compréhension du code...

L'index logguer avec un peu plus de 200 users onlines >>  0.0115 secondes
et 0.0186 secondes pour une liste de sujet...
 
Je vais m'attaquer aux topics maintenant ^^

Bah non, celui qui lis un bout de code genre :
$_REQUEST['blabla']
et le même avec :
$_POST['blabla']
 
Il saura d'office d'où ça vient, quelles actions ont pu être faites pour l'avoir, quelles sont les relations associées à cette variable, ce qu'on peut en faire, etc... C'est bien + pratique de catégoriser ses sources de données que d'avoir un truc archiglobal qui reprend les même données, mais en bordel finalement. Chacun sa méthode, le résultat sera le même de toute façon.

c'est la gestion des images persos qui fait que
+ les includes
utilise avec un cache d'opcode

Des image persos ?

Nan j'met pas d'cache ce serait tricher "faut assumer" comme qui dirait

 
Totalement faux. je peux très bien t'envoyer la même variable en post, get ou via un cookie, cela ne te donnera absolument aucune information sur la manière dont je te l'ai envoyé et sur ce que tu peux en déduire quant à son utilisation. Si tu te bases sur cette info pour résoudre des décisions, tu induis potentiellement des failles dans ton système.

des couleurs persos pardon
c'est pas tricher, là on parle d'optimisation mysql, pas php

Tient gizmo, c'est pas toi un jour qui m'avait sorti que plutôt que de faire  
 
$a= str_replace('pouet','plop',$a);
 
il fallait écrire :
 
$a= &str_replace('pouet','plop',$a);
 
?

 
Je pense que tu te trompes totalement. En plus d'une vérification sur la provenance exacte (get, post ou cookie) il faut bien sûr faire une vérification sur le contenu de la variable... mais ça que tu utilises $_REQUEST ou $_GET, $_POST ou encore $_COOKIE, c'est la même chose niveau vérifications... l'utilisation du $_GET, $_POST ou $_COOKIE est plus propre car elle te permet de savoir d'où provient exactement ta variable, ce qui réduit justement les problèmes de sécurité.

 
Je parle pas du contenu de la variable, on s'en fiche (toutes les données user issues des superglobales seront à vérifier à part que ce soit REQUEST ou les autres), je parle de la source qui a engendré cette variable. On peut très bien avoir un POST, un GET et un COOKIE qui porte le même nom mais avec un contenu différent, or REQUEST induit un ordre de recherche (variables_order ds php.ini) car il aura 3 fois le même nom dans le tableau, il va pas deviner lequel tu veux tout seul et se basera sur l'ordre défini au préalable dans la config, or c'est pas forcément celui qui est bon pour l'action en cours. C'est bien moins souple que de demander directement la variable que l'on souhaite après avoir éxécuter telle action... Globaliser à outrance ne sert à rien et ça n'ajoute pas de sécurité en +. On utilise bien les autres superglobales avec leur nom respectif (dont certaines ont dégagées de REQUEST y me semble), donc ça ne pose aucun problème de les appeler par leur nom.

P't'être ils ont les couleurs perso aussi les autres
Certe mais personne n'a parlé de cache de fichier ou quoi que c soit

aucun souvenir de celà, pourquoi?
 

 
Et comment tu vas me forcer à envoyer une variable en POST plutôt qu'en GET pour t'assurer que c'est la bonne valeur pour ton action en cours?

Index loggé avec 300 users : 0.0118 secondes  
 
Je suis heureux ^^

bah avec request tu fais comment ?
 
si tu fais un :
 
<?php
if(isset($_POST['variable']))
{
 
}
?>
 
t'auras beau foutre des trucs dans l'url, ça passera jamais. Après ça ne dispense pas de vérifier la variable, tandis qu'avec un request (avec l'ordre par défaut GPC, get post cookie)  
 
<?php
if(isset($_REQUEST['variable']))
{
 
}
?>
 
tu fous une variable en post, une variable en get bah hop, c'est la variable en get qui passe.

Scull > c'est quoi la config de ton serveur ?

P4 3GHZx2  

Ah ouais tu m'étonnes :-)
 
ça roxxe :-)
 
Vivement que t'ais 2000 connectés en direct, au moins on pourra comparer avec hfr, même si je pense qu'il y a moyen d'aller plus vite ;-)

 
Et donc? quel est l'intérêt du premier exemple? Tu comptes de temps en temps utiliser sur une même page une variable reçue en POST et son homonyme reçue en GET? Ce serait stupide. Quid des lib tierces qui utiliserait $_REQUEST et tomberait sur une de tes variables, au hasard? Quid d'un outil qui ne serait capable d'envoyer de que des requètes GET?

Oui je pense que je peu encore aller beaucoup plus vite. Les topics que j'ai pas encore refait doivent un peu influencer les temps de génération de l'index.
 
Sans compter que j'ai pas refait non plus les connectés online, la gestion des templates et la gestion de la publicité.  
 
Ouai c'est clair, vivement que j'arrive à 2000 onlines, mème si ces derniers temps hfr dépasse amplement les 2000 onlines

 
non pas du tout. Je n'utilise que ce que j'ai demandé, à savoir post ou get, pas n'importe quoi avec request    
 

 
Un outil qui ne serait capable d'envoyer que du get, mouais... HTTP remonte à loin quand même, faut pas pousser    
 
Par contre je n'ai pas compris ta question "Quid des lib tierces qui utiliserait $_REQUEST et tomberait sur une de tes variables, au hasard?"
 
"tomber sur une de mes variables" ? c'est à dire ?

t'es borné ou tu veux pas avoir tort pour une fois ?

Mais JUSTEMENT, tu reçois n'importe quoi avec POST ou GET, tu n'as aucune garantie, alors pourquoi pas REQUEST?
 

C'est pas une question d'ancienneté, c'est une question d'implémentation. Si tu veux faire un soft le plus petit possible, tu mets le moins de fonctionnalité inutile ou jugée redondante.
 

Si tu as un clash de nom entre une de tes variable et une variable utilisé par la lib tierce, tu risques de t'en rendre moins facilement compte si tu ne testes pas l'ensemble des valeurs.
Enfin, de tout façon, j'ai jamais compris pourquoi php avait introduit cette stupide notion de séparation entre les POST,GET et COOKIE...

quelle lib tierce ? je vois pas pourquoi il y aurait un problème avec la bonne méthode et pas avec la mauvaise (request) ?!
 
Ce qui est stupide à mon avis avec PHP, ce sont les register globals, les short open tags et les magic quotes.

Ce n'est pas PHP à ce que je sache, la notion de séparation fait partie des principes du web il me semble.

Parce que c'est une grosse connerie
En gros tu disais que comme c'était la même variable qui était modifiée et réassignée, fallait la passer par référence pour optimiser les perfs.

Aussi. Mais s'ils s'en tiennent à leur planning, on devrait en être débarassé avec php6.
 

Oui, mais ils sont la pour des raisons historiques (ce qui est la pire des raisons qui soit) et n'ont plus de sens rationel actuellement.
 

Dans ce cas, disons que j'étais encore optimiste à l'époque sur la manière dont était codé php

Excusez mon ignorance   , mais c'est quoi la différence entre les 2 lignes ?
Attention, je ne veux pas un débat sur ce qui est mieux vu que vous n'avez pas l'air d'accord, mais juste savoir ce que ça change.

Qui qu'a la plus grosse ?
 
Index (18 catégories listées) :
Loggué : 0.009s - MySQL : 0.004s
Non loggué : 0.009s - MySQL : 0.004s (Bizzare, pourtant y a les ampoules à gérer en plus, les cat visibles/invisibles, etc )
 
Liste des topics (900 topics, moui, spa énorme, mais j'ai pas mieux sous la main ) :
Loggué : 0.016s - MySQL : 0.009s
Non Loggué : 0.013s - MySQL : 0.006s
 
Dans un sujet :
Loggué (38 000 réponses - Avant dernière page) : 0.033s - MySQL : 0.007s
Non Loggué (11 000 réponses - Avant dernière page) : 0.028s - MySQL : 0.011s
 
Je viens de découvrir qu'en étant non-loggué, on a pas accès au système de navigation des pages (Pas possible de changer de numéro de pages quoi ) Plutot facheux

Il a pas dû prendre les mesures au même moments Donc y a dû avoir plus de membres connectés ce coup ci

Perso, je pars du principe que "Qui peut le plus, peut le moins", l'inverse n'étant que rarement le cas. Hors là, ça permet d'avoir une "précision" sur l'envoi des données.
 
Par contre, je dirais que par sécurité, ça semble logique de faire la séparation des données, car nulle n'est à l'abri, par exemple, de l'oubli d'un mres.
Imagine que PHP6 intègre les $_sessions dans le $_request, ça pourrait créer des failles énormes juste une pour un petit oubli de mres.
 
Après, je ne pense pas qu'une ou l'autre méthode soit à préconiser, ça fait juste parti de différentes méthodes de travail, perso, je préfère différencier les $_get des $_post des $_cookies et des $_files.

j'apel tout mes amis
 
Ben j'utilise mon site, c'était l'heure de pointe ^^

ba si, j'ai pas forcement envie qu'un gars envoie facilement des variables au serveur en bidouillant l'url, donc j'utilise $_COOKIE ou $_POST.

Ba disons que la façon autaine dont tu avais sorti ca m'avait marqué (genre t'es con ou quoi, tu sais vraiment pas coder), alors que c'est un énorme connerie
 

Euh... c'est pas tellement plus dur de copier ta page et de foutre les valeurs que l'on veut pour le POST. Pour le COOKIE, c'est très facile également, juste un peu plus long pour qui ne connait pas curl ou autre

Scull >  
 
http://213.251.172.99/?sid=1.05
http://213.251.172.99/log.php?log=smilie&sid=50.05

la deuxième ligne génère un warning php disant que t'es pas autoriser à passer le resultat par référence parce que c'est pas prévu pour. (et accessoirement en php il ne faut jamais passer une chaine de caractère par référence dans l'espoir d'optimiser les perfs, t'obtiendras le résultat inverse, parce que PHP augmente un compteur de référence en interne quand tu passes une string, donc il s'occupe déjà de l'optimisation).

Tout à fait, disons que le but de la sécurisation commence par le minimum pour ne pas faciliter la vie du piratin en herbe.
D'où mon exemple plus tot.
 
 
Sinon, c'était quoi l'"option" que tu avais proposé à Joce qui lui parait ridicule, juste pour ma culture, ça serait sympa de répondre.

ca complique la vie de pas mal d'apprenti hacker qui ont pas envie de se faire chier quand même

Tain, des fois quand tu causes, je me dis que j'suis vraiment une bite, j'ai rien compris.    
 
Oserais-je te demander d'expliquer "passer le resultat par référence" ?  

ouais, mais c'est pas ceux là que tu crains le plus non plus

t'as jamais fait de C/C++ ?