POO php

[Dark-Slade]

C est pas la meme chose ? Je dois me connecter après m être inscrit ou bien en validant mon inscription je suis connecté ?

A noter tu utiliseras ta classe a chaque fois que tu auras a manipuler ton personnage ? Est ce que ta question n est pas plutôt quand créer le personnage dans la bdd ?

Quand tu valide ton inscription tu dois te connecter, tu n'es pas connecter automatiquement.
Oui je pense utiliser la classe à chaque fois que j'en ai besoin, si par exemple un Guerrier combat contre un Mage il faut prendre en compte leur caractéristiques personnels donc réutiliser leur classe. Pour ta question sur la bdd, le personnage est crée dans la bdd à la validation de l'inscription enfaite je compte procéder ainsi :
Un joueur remplit le formulaire d'inscription, il choisi une classe de personnage (admettons ici qu'il choisisse Guerrier), ensuite il valide et à la validation dans la bdd est créer le membre avec les champs suivant : id, pseudo, mdp (coder en sha1),email et choix du personnage . De plus quand le joueur a valider l'inscription, l'objet issue de la classe Guerrier est créer et donc le membre "hérite" de ses caractéristiques, tel que le niveau, l'expérience, la force et autres...

Je ne sais pas si ma méthode est bonne mais je suis à mes débuts donc si quelqu'un à une meilleur idée je suis preneur

(sha, md5, c'est ok, j'avais juste peur que les passes traînent en clair dans le code )

Penses-tu qu'il faille aussi hacher l'email, car en cas de piratage l'email est en clair dans ma bdd, si tu as une technique pour hacher un email je voudrais bien que tu la partage :p

[Xenos]

L'email ne sera pas hashable, le pseudonyme non plus, car un hash détruit la donnée de base:
- Si on connait la donnée de départ, on peut calculer le hash, pas de problème
- Si on ne connait que le hash, pas la donnée de départ, alors on ne peut pas la reconstruire
Tout ce qu'on peut faire, avec les hash, c'est chercher (par brute force ou par des techniques mathématiques fiables, car le brute-force, t'en auras pour des milliards d'années :p) une donnée qui, une fois hashée, donne le même hash (ça s'appelle une collision: on a trouvé une donnée avec le hash qu'on souhaite, mais rien ne dit que cette donnée soit celle de départ).

Exemple de méthode de hash simple: la somme des chiffres.
Soit un nombre quelconque. Son hash est la somme de ses chiffres. Tant que cette somme est supérieure à 9, on recommence.
Par exemple, la donnée 5146532 devient 5+1+4+6+5+3+2=26 qui devient 2+6=8
Le hash de 5146532 est 8.
Si j'entre 5146532 dans ma fonction de hash, je récupère toujours 8.
En revanche, si on me dis "le hash est 8", je ne peux pas savoir que la donnée de départ était 5146532, mais je peux chercher une donnée qui a pour hash 8. Essayons 10, il devient 1+0=1, donc c'est pas le bon hash... J'essaie 11... 12... 17... ah! 17, ca marche! Heu... 17 n'était pourtant aps la donnée de départ, mais elle a le même hash! :o
Donc si c'était un mot de passe, entrer "17" ou "5146532" donnerait le même résultat: le hash étant 8, le mot de passe est considéré comme valide.

En pratique, avec md5 (et encore plus avec sha), les collisions sont bien trop difficiles à trouver pour qu'on puisse découvrir un mot de passe ayant un hash donné (sauf si on calcul le hash de tous les mots du dictionnaire et qu'on cherche, dans ces hash, le hash qu'on veut "rétro-calculer"... Exemple: si "cheval" est mon mot de passe, son md5 est 9f87ec4fda4a91dd564f6bdf1ab301c8, et d'après les sites webs comme gromweb qui ont déjà calculé le md5 d'un tas de mots du dico, on sait que "cheval" a le bon hash, on remonte le mot de passe, d'où la raison pour laquelle il faut utiliser un grain de sel, non-constant si possible).

Bref, tout cela pour dire qu'un hash ne permet pas de retrouver la donnée initiale, donc, si tu hash les mails ou les pseudo, tu ne pourras plus les "décoder".
Si l'e-mail est publiquement affiché sur le site web, inutile de le sécuriser dans le code PHP.
Si l'e-mail est totalement privé (seul l'utilisateur du compte est censé le connaitre), le masquer me semble, là encore, peu utile, car ce ne sera pas par là que les pirates passeront (pour lire ces données, il faudrait pouvoir injecter du code php et donc soit avoir accès au FTP, soit avoir une injection PHP, dans les deux cas, la connaissance du mail d'un joueur ne sera pas ton soucis prioritaire, puisqu'un pirate pourra injecter un code PHP arbitraire :p).

Si vraiment tu tiens à le masquer, tu peux utiliser mcrypt_encrypt et mcrypt_decrypt. En ce cas, le mot de passe qui sert au cryptage ne doit pas filtrer dans le code PHP... Ce qui pose un problème quand tu vas devoir déchiffrer le mail :p

Jouer sur les cryptages dans les codes PHP est, quasiment 100% du temps, inutile car si on a accès au code PHP, on trouvera comment récupérer les clefs de cryptage et on pourra décrypter. En revanche, on ne laisse pas traîner les mots de pass et les données hashables, car ces données ne sont pas censées être "lisibles" par le serveur: le serveur ne doit que manipuler leur hash, et jamais la donnée d'origine, qui sinon pourrait fuir.

[Dark-Slade]

Merci beaucoup Xenos de m'avoir éclairer sur le hash je comprends maintenant beaucoup mieux comment cela se fait, à vrai dire j'utilisais le sha1 sans vraiment savoir ce qu'il se passait derrière, je l'utilisais comme boite noire ^^ enfaite crypter le mail ne sert à rien donc je vais juste crypter le mot de passe.

Par contre je n'ai toujours pas eu de retour sur l'architecture de mes classes donc si quelqu'un ayant bien assimiler le concept de l'OO passe par là, ça serait aimable de sa part de m'aider

[Xenos]

De rien

Je n'aurai pas fait hériter le membre (utilisateur humain) du personnage du jeu. En effet, pour moi, c'est plus logique de dire "le joueur humain, instance de 'membre', possède un personnage de classe virtuelle 'personnage', qui est une instance de 'Guerrier'".
En termes UML, ca se traduit par l'aggrégation je crois...
En termes de code, cela revient à

Code PHP :

<?php 

abstract class Personnage //Classe non-instanciable, c'est à dire une classe qui sert "d'ensemble", de parent, à plusieurs classes

{

}

class Guerrier extends Personnage

{

// Code du guerrier

}

class Nain extends Personnage

{

// quelqu'un veut un chiantos?

}

class Mage extends Personnage

{

// c'est normal que le Nord soit à l'Est sur la carte de la magicienne?

}



//------------- séparé ---------

class membre // l'utilisateur enregistré, il n'extends rien du tout

{

private $personnage; // cet attribut recevra l'instance du personnage (Mage, Guerrier,...) du membre



public function setPersonnage(Personnage $p_personnage) // Cette méthode attache un personnage déjà instancié au membre

{

$this->personnage = $p_personnage; // $p_personnage est de type "Personnage", classe abstraite, donc c'est une instance d'une classe qui doit hériter de "Personnage"

}

} 

[Dark-Slade]

Merci beaucoup j'ai compris ^^ c'est un peu dur à assimiler ce concept d'OO quand même :p

[php_addict]

c'est un peu dur à assimiler ce concept d'OO quand même :p

oui c'est bien pour cela que je ne fais pas de POO :-)

[Dark-Slade]

c'est un peu dur à assimiler ce concept d'OO quand même :p

oui c'est bien pour cela que je ne fais pas de POO :-)

et dans le cadre de création d'un jeu par navigateur, cela n'est pas trop contraignant ? Je veux dire par là peut être que pour un "lourd" projet cela serais plus simple, plus rapide et plus organiser en POO non ?

[Xenos]

Je trouve aussi, oui, que pour un projet dépassant le jeu de morpion, la POO facilite grandement la vie.
Eclerd est totalement impossible à maintenir, mettre à jour, ou simplement relire, même si j'en suis l'auteur :p Le procédural atteint ses limites quand on attaque un jeu avec des interactions et des composants/agents multiples.