Je suis en train de faire un forum en php et donc je regarde un peu partout comment ca marche. Et j'ai remarqué que la plupart mettent un cookies pour reconnaitre la personne (normal). Mais la ou c'est bizarre, c'est qu'ils incluent aussi le password sous un forme cryptée, comme ici.
 
Alors ma question est: y a-t-il un intéret de cripter le password dans le cookie? sachant que si je copie le cookies ailleurs il marche et que le password préremplit dans les formulaire est le vrai password (donc lisible dans le code HTML).

le crypter évite (à mon humble avis) à qq'un de pouvoir le lire à l'insu de ton plein grè.
De toute façon rien n'empeche de refuser le cookie et de devoir saisir ton pseudo/mot de passe à chaque fois.

bah oui, mais comme il est repris en clair dans le formulaire de post, ca sert a rien!

il est pas en clair (en tout cas pas ici) puisque c'est un champ password.

et alors, tu fais view source et tu l'as... c'est pas difficile. Qualqu'un qui sait lire les cookie sait afficher le code HTML d'une page

putain jsuis trop crevé moa  
alors le cryptage est peut être superflu mais ça sert à rien non plus de se faire chier à vouloir protéger ton forum autant que fort knox    
le mieux serait de le protéger contre le flood (type le plus courant d'attaque), en vérifiant la page d'ajout, pour éviter le flood depuis un script externe.

salut,
 
il existe une autre solution que les cookies du moins en grande partie et il faut saisir le passe au moins une fois pour l'ensemble du site.
 
Mais bon le propre de la sécurité c'est de ne rien dire, donc je me tais

[edtdd]--Message édité par Barbarella--[/edtdd]

sh@rdar>> c'est pas pour le transformer en tour imprenable mais juste pour savoir si ca apportait un plus ou non. visiblement non, merci.
 
Barbarella>> oui, je sais, suffit de jouer avec les sessions.

les sessions avec un forum, rien de tel pour tout faire ramer......
surtout qu'en général c'est la partie la plus fréquentée d'un site, le serveur aura intérêt à suivre.

ca bouffe tant que ca? plus que les accès aux db?

en fait le pb c'est que à chaque fois qu'un visisteur arrive sur ton site, le serveur doit vérifier/ouvrir/fermer une session, mais il délivre en plus les pages et envoie les requêtes au serveur BDD, tout ça ça bouffe des ressources si en plus t'as quelques centaines de visites simultanées, le serveur aura du mal à tout gérer.
 
on s'imagine à tort que les requêtes ralentissent, mais en général, elles sont plus rapides que tout les traitements PHP/ASP qui servent à traiter les résultats.
 
Ex : plutot que de faire des boucles while($val=mysql_fetch_array($Req)), essayes plutôt de faire une seule query SQl en CONCAT qui te sortira tous les résultats, gain de rapidité garanti !!

oui, mais la mise en page de concat est assez limitée et ca ne se prête pas vraiment a un forum.

bin tu peux faire une mise en page exactement de la même façon qu'en traitant les lignes en boucle php, mais là la query te sors la ligne d'un coup.
 
un autre exemple : quand tu  mets les titres, messages et profils dans des tables séparées, tu aurais tendance à faire ça :
 
$Query = ("query qui récupère les messages" );
while ($Query......) {
  query qui récupère les profils;
  affichage des messages;
  affichage des profils;
}
 
eh bien tu peux optimiser le tout pour ne faire qu'une query et récupérer d'un coup le nom du profil qui a posté ton message.
ça donne une query comme ça :
 
SELECT * FROM forum_post LEFT JOIN forum_profils ON forum_profils.Auteur=forum_post.Auteur WHERE Pere=$post ORDER BY forum_post.Date
 
et là tu gagne encore du temps puisque les informations des deux tables sont sorties en une seule query.
jm'en va lancer un topic sur l'optimisation des query pour forum moi..

non non, je fais pas comme indiqué plus haut, ni comme avec ta méthode. je fais bien un select mais sans joindre les 2 tables, comme ca je gagne encore du temps.

explique, je voudrais bien savoir moi

simplement par SELECT noms_des_champs.nom_des_tables FROM nom_des_tables WHERE ...
 
Ainsi tu évites de créer une vue par une jointure, c'est du temps de gagné.

euh... c'est exactement la même chose, ta query est en fait un JOIN  

non, le résultat est le même, mais pas la manière de travailler. Jan un Join, il va crée un vue, donc une sorte de table fantome qui prend de la place mémoire. C'est utile si on a beaucoup de champs a vérifier avec plusieurs interactions, car alors la jointure est fait et il ne doit pas parcourir les table a chaque fois. Mais pour un forum ou tu ne sort pas plus de 20 réponses a la fois, cette manip est beaucoup plus lourde car elle joint la totalité des 2 tables, alors qu'on en utilise qu'une tout petite partie.

je me suis mal expliqué,en fait quand tu fais une sélection de champs  sur plus d'une table MySQL effectue un join (dixit la doc). Donc la manière (et le résultat) sont les mêmes   .
 
Par contre tu peux joindre les tables sans inclure tout les champs c'est de l'optimisation.

Ah bon, ca je savais pas, c'est pas comme ca dans toutes les DB en tout cas (Access par exemple). Bon dans ce cas, effectivement, ta méthode est mieux, je vais changer dans mon code.

on devrait faire un thème sur l'optimisation MySQL, mine de rien y a pas mal de fonctions peu utilisées qui évitent souvent des traitements lourds au niveau script.
 
idem concernant les types de champ, je crois qu'il y a un tutorial bien foutu sur phpfance.com

ouais, moi je cherche désespérement une table qui donnerait pour des valeurs types (100 enregistrement de 10 champs par exemple) le nombre de cycle processeur et la taille mémoire utilisée.

comment faut faire alors pour reconnaitre quelqu'un tout au long des pages ?

[edtdd]--Message édité par art_dupond--[/edtdd]

il reste la possibilité d'utiliser un cookie qui a la même durée de vie que celle du browser (pas de date d'expiration spécifiée).

oki merci
 
 
sinon ca m'interesserai le truc sur l'optimisation mysql

au fait, c'est possible de savoir si le cookie a ete accepte ?

oui, suffit d'intérogger une variable du cookie, si elle n'existe pas, c'est que le cookie a été refusé.

oki...

Sh@rdar > n'hésites pas a faire ton topic "optimisation mysql "; )