AccueilCodesTutorielsForumsEmploiLivresGuide achatConnexion

  • CodeS-SourceS
  • RSS CodeS-SourceS
  • CodyxBot, le Bot GTalk & MSN qu'il vous faut !
  • Générez des revenus avec vos codes, scripts et tutoriaux
  • Aide à la navigation du site
begin process at 2009 07 09 22:03:40
Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

8 commentaire(s) de lmame sur des sources sur tout CodeS-SourceS

Le : 09/05/2008 22:24:33
Source : CLASSE SIMPLE EMAIL
Pour ce qui est de mon avis (soulant), j'ai repris ce que tu disais " cependant il me semble que mettre des return est aussi fatigant que de lancer des exceptions".
Dans mon sens saoulant = fatigant.

Sinon, y'a une erreur là:
if($exp = filter_var($exp,FILTER_VALIDATE_EMAIL))
dans le meilleur des cas, c'est ==, mais il vaut mieux tester si tu reçois false:
if(filter_var($exp,FILTER_VALIDATE_EMAIL)===false)

Pour ce qui est des exceptions, c'est simple. Une exception doit rester... une exception et non pas une règle, et puis un utilisateur ne pensera peut être pas au fait que tu ais utilisé des exceptions et soit obligé de faire un try / catch sous peine de voir planter son programme.
Imagine qu'il y ait:
prise de commande
validation de la commande
envoi d'un mail
autre traitement
s'il ne pense pas à faire un try / catch et que par malheur ta classe sorte une exception non traitée, la partie qui suit l'envoi du mail ne sera pas faite.

Maintenant, si tu as envie de bosser de cette manière, dans cette philosophie après tout pourquoi pas :) le tout c'est de choisir et de t'y tenir.

Le : 09/05/2008 21:20:30
Source : CLASSE SIMPLE EMAIL
Bah si c'est juste pour faire un exemple, ok.
Ceci dit, pour les exceptions, je trouvais juste lourdingue d'obliger l'utilisateur de ta classe à utiliser un try / catch dans le code principal, c'est tout :)

Ceci dit, tu utilises $confirmation dans ta classe, mais il n'est jamais initialisé, il sert à quoi?
A moins que ce soit le résultat du mail?
return  "Your email have been sent";
dans ce cas il faudrait plutôt faire: $this->confirmation="Your email have been sent";

-> Bon, sinon ça sert pas à grand chose de faire le ==TRUE:
        if(($this->verifAdMail($this->exp)&&$this->verifAdMail($this->dest)
            &&$this->verifCont($this->cont)&&$this->verifSubject($this->subject))==TRUE
soit tu ne mets rien (pas de ==TRUE), soit tu mets ===TRUE pour vérifier qu'en plus c'est un booléen, mais bon, très honnêtement vu que c'est ton code, tu peux t'en dispenser.
D'autre part, comme tu mets des throw exception partout au cas où la vérification échoue on se demande même si ça sert à quelque chose de mettre ça dans un if? Autant faire appel aux méthodes directement vu que ta classe va "planter" en cas de problème.
$this->verifAdMail($this->exp);
$this->verifAdMail($this->dest);
$this->verifCont($this->cont);
$this->verifSubject($this->subject);

-> Ensuite, pour ta vérification d'email:
    private function is_email($exp){
        if(!empty($exp)){
        $exp = filter_var($exp,FILTER_VALIDATE_EMAIL);
Ca peut ne pas être correct. En effet filter_var renverra bien un email dans le cas où $exp est un mail correct, mais il peut également renvoyer un booléen false si le check a échoué! Dans ce cas $exp ne sera pas empty mais $exp sera failse mais ta fonction renverra true...
D'autre part, tu changes la valeur de $exp, ce qui pourrait poser soucis par la suite...

Pour les fonctions non compatibles Windows, tu peux déjà voir si elles sont accessibles par des tests sur l'existence des fonctions.

Comme disait mon prof d'informatique: "un bon programmeur est un fainéant, il fait aussi peu de code possible." mais ça n'est pas à prendre non plus au pied de la lettre. Si déjà faire une classe te saoule (return) imagine plus tard dans un vrai soft... Tu ne vas pas pouvoir caser des exceptions de partout sinon imagine la tronche de ton code.


Le : 09/05/2008 18:01:43
Source : CLASSE SIMPLE EMAIL
Bah s'il aime tant que ça les exceptions et que c'est une "règle" dans son code, ok.
C'est juste que je sais que je n'utiliserai pas une classe en l'état qui ne fonctionnerait qu'avec ça, ça revient à écraser une fourmi avec un caterpillar.
Il y a évidemment d'autres solutions comme le "message" qu'il appliquait avant qui pourrait contenir le message d'erreur (ou de validation) et les méthodes renvoyer dans ce cas un booléen en cas de succès / échec. Mais bon, après c'est une religion personnelle je suppose ^_^

Le : 09/05/2008 12:28:44
Source : CLASSE SIMPLE EMAIL
Quelques remarques aussi de mon côté ^_^
-> Tu utilises des fonctions checkdnsrr qui ne fonctionnent pas sous Windows (cf help PHP),
-> l'utilisation de "mail" est parfois bridée chez les hébergeurs et peut virer au cauchemar dans le cadre d'un serveur perso, donc je rejoins depression, prévois un cas où tu peux utiliser un serveur SMTP avec login / mot de passe,
-> tu encapsules ton code dans un if pour l'envoi du mail:
        if(!empty($this->exp)
        &&!empty($this->dest)
        &&!empty($this->cont)
        &&!empty($this->subject)){
  autant faire un return si une des variables est empty (à la première), le code sera plus lisible, ça fait une indentation pour rien là, d'autant plus qu'au final tu testes les variables deux fois avec le else ensuite.

-> je pense qu'il manque aussi la gestion des erreurs dans tes "set":
    public function setDest($dest){
        if($this->verifAdMail($dest)){
            $this->dest=$dest;
        }
    }
Si le $dest est incorrect, le $this->dest sera donc à "" et dans le meilleur des cas ton utilisateur aura un message "Le champ du destinataire est vide". Or il était pas vide, il était incorrect.
Bref peut être que tes setxxx devraient revoyer true ou false (ou un message d'erreur) selon que la verif a marché ou non. Comme ça tu pourrais dire à l'utilisateur "adresse mail incorrecte" ou un truc dans le genre.

Dans ton code "principal":
-> tu fais un try / catch dans ton code. C'est sympa, mais un peu inutile à mon sens. Si le mail n'a pas été envoyé, renvoie un booléen ou un message texte plutôt par un return classique.
D'autre part, sauf erreur je vois qu'en cas de mail envoyé avec succès tu utilises $this->message... Or cette variable n'est jamais utilisée (dans le code principal ou la classe), ni même définie dans la classe?

Bref un return "mail envoyé avec succès" ou return "erreur lors de l'envoi du mail" me semble suffisant. Lever une exception pour ce style de code me paraît too much, surtout si quelqu'un utilise ta classe ensuite.

Le : 21/01/2008 13:26:15
Source : TWC LE PREMIER SITE EN CMS DES TOUTOOS
Oui pour le md5() c'était juste pour donner une méthode basique de cheminement et de code pour php. Comme ce genre de chose se retrouve très aisément dans les codes / tutos sur internet ça permets déjà de lui donner une idée.

Après bien évidemment ce n'est pas la panacée le md5, loin de là pour les raisons déjà données :)

Ensuite pour la sécurisation totale d'un soft ça peut aller beaucoup plus loin, du log systématique des query / login / accès à l'utilisation de logs générés par mod_security que l'on peut installer pour Apache. Mais bon comme vous l'avez dit, tout est une question de juste milieu tout de même :)

Le : 21/01/2008 12:01:49
Source : TWC LE PREMIER SITE EN CMS DES TOUTOOS
Euh... Je ne pense pas que nous ayons été très agressifs :)
D'autre part, tu dis que tu travailles sur la V2 et sur les points signalés, très bien, il faut comprendre que nous revevons ici car on reçoit des notifications par mail, on ne passe pas sur ton site tous les jours pour voir où tu en es ce sujet sert à ça...

Pour les mots de passe, je pense que tu fais une confusion.
Si l'on te parle de crypter le mot de passe, c'est lors du stockage dans la base de données pour qu'il ne soit pas "en clair" dedans.

Je donne un exemple en md5:
Lors de l'inscription, ton utilisateur choisit comme mot de passe "coucou", tu le récupères dans ton code PHP et tu calcules sa signature en md5 (il suffit d'utiliser la fonction php md5() ) ce qui donne "721a9b52bfceacc503c056e3b9b93cfa" (normalement). L'avantage du md5 c'est que tu peux calculer une signature, mais tu ne peux pas, en partant d'une signature, retrouver le mot de passe originel (sauf en utilisant des dictionnaires ou le brute force, mais c'est une autre histoire).
Donc tu stockes dans ta base de données la signature "721a9b52bfceacc503c056e3b9b93cfa" pour cet utilisateur.

Quand ton utilisateur reviens et se loggue, il entre son mot de passe "coucou", tu calcules la signature du mot de passe qu'il a rentré (coucou) en md5 et tu la compares à la signature md5 qui est dans ta base de données.

En faisant comme ça, tu protèges tes utilisateurs car si la bdd se fait voler ou exploiter (sql injections ou autres) au moins les mots de passe seront cryptés.


Comme tu le vois, il n'y a donc aucune relation entre cryptage, et nombre de caractères dans le mot de passe ici :)

Si l'utilisateur décde de changer de mot de passe, tu peux toujours vérifier que l'ancien est correct avant de le changer pour un nouveau. En revanche, tu ne pourras pas toi le récupérer.
Ce que font la plupart des sites c'est qu'en cas de perte du mot de passe, ils l'écrasent par une chaîne aléatoire et qu'ils envoient le nouveau mot de passe sur le mail donné lors de l'inscription.

Le : 14/01/2008 09:42:05
Source : TWC LE PREMIER SITE EN CMS DES TOUTOOS
Salut :)
Même remarque pour la sécurité, en Mysql il suffit de penser juste au typage et à mysql_real_escape_string (enfin, en gros...), autant le faire dès le départ que de se fader tous ses fichiers (quand on a pas de POO, c'est là qu'on voit que ça sert :) ).

Autre chose, toujours au niveau de la sécurité, apparemment le mot de passe est en "clair" dans la base de données. Déjà tu pourrais le stocker en md5() là aussi en une fonction tu sécurises un peu plus.

Sinon le fait de mettre des "@" devant toutes les commandes mysql juste pour cacher la misère en cas de plantage me paraît pas trèèèès judicieux :)
Autant faire une classe pour ça et traiter l'erreur éventuel (surtout si comme tu le dis c'est un proto et que tu veux savoir où et pourquoi ça plante).

Pour stocker les infos bdd tu crées un fichier php (system/data.php) mais sans vérifier s'il a bien été crée (ou si tu as les droits pour dans le dossier en question) ou pas et ensuite tu l'utilises dans pas mal de fichiers. Là encore pas de tests à l'ouverture en création du fichier.

Autre chose, dans system/modules.php (et aussi ailleurs):
if(empty($name) OR empty($actif))
if ( $actif == 'Oui' AND $name == 'Navigation')
tu devrais voir les opérateurs de comparaison booléens, || pour le OR et && pour le AND.


Le : 03/07/2004 11:13:33
Source : CALLBACK DLL [DEMANDE FORUM]
C'est exactement ce que je cherchais à faire depuis un moment...
Merci beaucoup ;)


1


Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Comparez les prix Nouvelle version


HTC Magic
Entre 429€ et 429€


Visiter le guide achat

Photothèque Nouveau !

Photo pretty girlsPhoto alphabet langue des sourds
Photo femme, plage, bien être, soleil, vacances, été, détente, reposPhoto femme, Plage, Bien être,

Visiter la photothèque


Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,187 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.