SYSTÈME D'IDENTIFICATION
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
-
1 juil. 2008 à 18:37
jadu Messages postés 217 Date d'inscription mercredi 26 juillet 2006 Statut Membre Dernière intervention 16 août 2018 - 9 juil. 2008 à 11:51
jadu Messages postés 217 Date d'inscription mercredi 26 juillet 2006 Statut Membre Dernière intervention 16 août 2018 - 9 juil. 2008 à 11:51
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/47175-systeme-d-identification
https://codes-sources.commentcamarche.net/source/47175-systeme-d-identification
9 juil. 2008 à 11:51
Que les administrateurs d'un site puissent intervenuir à l'intérieur des messages postés par les contributeurs, avec apparition d'un signe, d'un logo ou de toute autre chose signalant que le message d'origine a été modifié !
C'est un bon sujet de travail pour les pros, non ? ;-)
8 juil. 2008 à 18:57
Et comme je ne peux pas juste modifier un message...je suis embêté :-)
8 juil. 2008 à 14:57
Alors, pour le maintien du bon esprit de ce site sur lequel je m'enrichis chaque fois que j'y passe, ne serait-il pas possible d'enlever les propos acides ou disgracieux lorsqu' "Amende honorable" a été faite par les contributeurs ???
Il est vrai que je n'avais lu que les interventions du début, et comme dans ces premières l'acidité coulait à flot je n'avais nullement cherché plus bas ! ==> (Je fais donc amande honorable également - et demande à faire enlever ma remarque ci-dessus malvenue, donc !)
Et que tout reprenne le cours limpide et serein !
7 juil. 2008 à 19:50
7 juil. 2008 à 09:57
non, il n'y a pas que des pros ici et je suis stupéfait de voir ta manière de prendre les remarques faites sur ton code.
Je suis autodidacte et je sais qu'il est meilleur de ne pas mélanger HTML et PHP ! Mais bon, je n'y suis pour rien, j' n'ai comme argument pour mon propos que '"je l'ai lu PARTOUT !".
Sinon, rien qu'avec ta façon de répondre, vu le profond mépris que tu as des autres, je n'ai pas du tout envie de voir si ton truc est utile à quoi que ce soit !
Je fais bien de lire les commentaires d'abord, çà m'évite de polluer mes sites avec de mauvaises influences !
Bonne continuation Farfadh ! Mais je serais content d'apprendre que tu as changé !
4 juil. 2008 à 11:39
function getUserVar($var)
{
if(isset($_SERVER[$var]))
return $_SERVER[$var];
elseif(isset($_ENV[$var]))
return $_ENV[$var];
$ret = @getenv($var);
if($ret !== false)
return $ret;
return '';
}
Sinon petit détail mais qui peut avoir son importance dans certain cas... il est préférable, d'une manière générale, de faire des comparaisons typés en php d'une part parce que comme ça tu est sur que ta variable a bien la valeur (et le type) que tu attend et d'autre part parce que le temps d'éxécution est meilleur, bon c'est pas grand chose mais c'est toujours ça de gagné... à partir du moment ou tu sais de quel type doit être ta variable mieux vaut faire une comparaison typé... en php...
false == 0
mais
false !== 0
;o)
@ tchaOo°
4 juil. 2008 à 11:23
Pour les return j'avais bien compris mais ce que je veux dire c'est que tes bloc de condition contenant tes includes sont vide que ton include retourne true ou false tu n'effectue aucune opération... donc c'est inutile tout du moins en l'état... .. .
Pour l'antiflood on est d'accord mais la technique de la désactivation du compte à réactiver via un lien est lourde à mettre en place à mon sens... après tout dépend du site dans lequel c'est intégré mais pour un petit site c'est à mon sens trop... pourquoi mettre une porte blindée à une grange... .. . ;o)
Pour le reste je te poste ça quand j'aurais 2 minutes je suis au taf là... .. .
@ tchaOo°
3 juil. 2008 à 23:55
Au fait, un truc qui ne va pas te faire plus plaisir qu'à moi, les opérateurs ?: sont moins performants que la structure if()else. C'est con, hein ? Du coup je me suis fait une fonction spéciale :
array_get($cle, $tableau, $defaut= NULL)
// récupère une valeur dans un tableau grâce à sa clé
// renvoie cette valeur, convertie si nécessaire
// renvoie la valeur par défaut en cas d'échec
{
if(!is_array) return($defaut);
if(!array_key_exists($cle, $tableau)) return($defaut);
return($tableau[$cle]);
}
Du coup, je peux écrire directement :
$remote_addr= array_get('REMOTE_ADDR', $_SERVER);
L'intérêt de la forme actuelle avec les return, c'est que je teste le résultat des scripts les uns après les autres avec les if successifs, mais j'aurais pu mettre des and entre chaque include, ça aurait été pareil. En fait, j'avais habitude d'imbriquer les if parce que je ne savais pas bien quelle forme d'opérateurs binaires effectuait ou non les opérations sur tous les opérateurs, ou seulement jusqu'à ce qu'on soit sûr du résultat. Depuis, j'ai fait les tests pour savoir, mais je n'ai jamais changé mon écriture en conséquence.
Pour la petite histoire, je me méfie des opérateurs parce que selon le langage, les expressions autour sont calculées de différentes manières. Dans Visual Basic, je m'étais fait avoir parce que celui-ci calculait les arguments des fonctions de droite à gauche et j'ai mis du temps à comprendre pourquoi mon programme ne marchait pas.
De toute manière, la question ne se pose plus, je vais réécrire cette partie du script.
Pour l'anti-flood je me suis mal exprimé. En fait il y a deux méthodes à utiliser pour l'anti-flood. Soit on peut bloquer jusqu'à ce que le temps passe et qu'on puisse faire une autre tentative, soit on peut carrément bloquer toute nouvelle tentative depuis une IP donnée jusqu'à ce que l'utilisateur en question la débloque depuis un lien dans sa boîte mail.
Sinon, je suis intéressé pas tes méthodes pour sécuriser les sessions.
@plouche
3 juil. 2008 à 21:29
@ tchaOo°
3 juil. 2008 à 21:21
Cependant je voudrais préciser une chose... à aucun moment dans mon 1er post (et celui juste après) je ne dis que ton code est nul, ne vaut rien, est illisible, etc... bien au contraire il y a du bon, il n'est pas utile de tout modifier loin de la... je donne juste mon avis sur ce que j'ai vu de ton code (et je le dis au début de mon post je ne l'ai pas vu entièrement) et sur la discution au sujet des select *, short open tag et autre mvc... d'ailleurs pour revenir au mvc à aucun moment je n'en parle, je parle juste des perfs concernant le mélange html et php... .. .
Il va de soit que si le principe du mvc est indispensable sur des codes complexe il ne l'est pas du tout sur des code plus simplifiés comme ta page d'exemple source de tout ce remu ménage (lol ;o) tout du moins le mvc radical méthode je sépare tout parce que mélanger contrôleur et vue mais en gardant le modèle séparé ça reste du mvc... moi même j'ai codé, je code et je coderais des scripts ou le php est mélangé au html, forcement si j'ai 3 pages de code à faire quel intérêt de tout séparer, et dans ces cas là je préfère aussi mélanger html et php plutôt que de passer par des echo tout simplement parce que c'est bien plus simple de bien indenter le code de cette manière et c'est du temps de gagné lorsqu'en suite tu veux visualiser la source de ta page dans le navigateur et le tout sans perte de perf... cependant et tu ne pourra pas dire le contraire dès que tu passe sur des codes plus complexe, plus structurés le modèle mvc devient indispensable... le seul reproche que je pourrais faire sur ton code au sujet du mélange vue/contrôleur c'est ne pas avoir externalisé les messages d'erreur dans un fichier à part en les déclarant par exemple dans des constantes que tu réutilise dans le modèle et dans le contrôleur ce qui permettrait de les modifier beaucoups plus facilement/rapidement... .. .
Pour ce qui est des select ça dépend de différents facteur... nombre de champs, type de champs et il me semble que le nombre d'entrées peu aussi jouer dans certains (avec les champs de type binaire si je me souviens bien, à vérifier)... toujours est il que la plupart du temps il est préférable de passer par une sélection nominative... .. .
Pour les return je suis d'accord sur le fond mais c'est la forme actuelle qui me fait dire...
"je n'en vois pas l'intérêt c'est à mon avis une erreur de conception"
c'est le seul moment il me semble ou j'ai critiqué ouvertement ta source, je m'excuse si tu as pris ça pour un jugement de valeur sur ton travail ça n'était pas le but... mais je persiste à dire que je ne vois pas l'utilité de retourner un booléen... d'autant plus que dans ton exemple le block de condition est vide... .. .
Par contre plutôt que de parler de mvc et de l'exemple moi j'aurais plutôt parlé de class... j'aurais bien vu ton code sous forme d'une petit classe... ça simplifierait pas mal de chose je pense... .. .
Pour l'ip moi j'utilise ce code réadapté de phpMyAdmin... il n'est pasd infaillible mais reste plus fiable car il permet de filtrer la plupart des proxy...
function getUserIp()
{
static $_userIp, $_proxyIp;
if(empty($_userIp))
{
$direct_ip = '';
$remote_addr = (isset($_SERVER['REMOTE_ADDR'])) ? $_SERVER['REMOTE_ADDR'] : '';
$http_x_forwarded_for = (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : '';
$http_x_forwarded = (isset($_SERVER['HTTP_X_FORWARDED'])) ? $_SERVER['HTTP_X_FORWARDED'] : '';
$http_forwarded_for = (isset($_SERVER['HTTP_FORWARDED_FOR'])) ? $_SERVER['HTTP_FORWARDED_FOR'] : '';
$http_forwarded = (isset($_SERVER['HTTP_FORWARDED'])) ? $_SERVER['HTTP_FORWARDED'] : '';
$http_via = (isset($_SERVER['HTTP_VIA'])) ? $_SERVER['HTTP_VIA'] : '';
$http_x_coming_from = (isset($_SERVER['HTTP_X_COMING_FROM'])) ? $_SERVER['HTTP_X_COMING_FROM'] : '';
$http_coming_from = (isset($_SERVER['HTTP_COMING_FROM'])) ? $_SERVER['HTTP_COMING_FROM'] : '';
if (!empty($remote_addr))
$direct_ip = $remote_addr;
$proxy_ip = '';
if (!empty($http_x_forwarded_for))
$proxy_ip = $http_x_forwarded_for;
else if (!empty($http_x_forwarded))
$proxy_ip = $http_x_forwarded;
else if (!empty($http_forwarded_for))
$proxy_ip = $http_forwarded_for;
else if (!empty($http_forwarded))
$proxy_ip = $http_forwarded;
else if (!empty($http_via))
$proxy_ip = $http_via;
else if (!empty($http_x_coming_from))
$proxy_ip = $http_x_coming_from;
else if (!empty($http_coming_from))
$proxy_ip = $http_coming_from;
if (empty($proxy_ip))
$_userIp = $direct_ip;
else
{
$_proxyIp = $direct_ip; $is_ip preg_match('~^([0-9]{1,3}\.){3,3}[0-9]{1,3}~', $proxy_ip, $regs array());
if ($is_ip && (count($regs) > 0))
$_userIp = $regs[0];
else
$_userIp = '?';
}
}
return $_userIp;
}
La méthode controlant le nombre de tentative de connexion et l'antiflod sont la même technique puisqu'en cas d'attaque brute force le bot sera bloqué au bout de la Xème tentative... après pour ça, les id contre le vol de session, ne pas faire transiter les in fos en clair, etc c'est juste des techniques que j'utilise pour sécuriser certains de mes scipts... .. .
Voili voilou... .. .
@ tchaOo°
ps : les endif mon effectivement tout de suite fait penser au C... .. . :o)
3 juil. 2008 à 18:23
J'ai aussi une petite remarque à faire concernant le MVC:
Quand on voit maintenant que des frameworks comme le Zend Framework ou Symfony utilisent ce type de procédé, alors je me dis qu'un bon nombre de personnes se sont posé la question avant nous ! ! !
De plus, les autres langages utilisent également cette méthode(JAVA, .NET) et c'est un pattern qui a fait ses preuves (normal c'est un design pattern :-).
3 juil. 2008 à 17:54
Nous sommes tous, il me semble, des professionnels avec beaucoup d'expérience derrière nous, et à ce titre nous nous sommes très mal comportés. Il me semble urgent d'arrêter tout de suite ces discussions stériles et de repartir sur des bases saines, parce que quand je relis tous nos messages, il n'y en a pas eu une personne pour rattraper l'autre, et je m'inclus dans le tas. A vouloir défendre nos positions, on en a oublié l'essentiel, c'est l'esprit de communauté et donc d'équipe. Laissons de côté nos différents et tentons d'avancer. Je vais donc mettre mon orgueil de côté et tenter de nous départager avec autant d'objectivité que possible, car le gros du problème est en réalité la communication entre nous.
En règle générale :
J'ai eu tort d'insister sur certains points, mais mettez-vous à ma place : que penseriez-vous des opinions de quelqu'un si, quand vous les vérifiez, vous découvrez qu'au moins une partie est sans véritable fondement, quand elles ne sont pas totalement erronées ? Dorénavant, j'arrête le "quotewar" qui a l'air d'être anti-productif, et je veillerai à ne plus avoir de comportement ou de propos qui enveniment les conversations.
J'insiste toutefois sur le fait que vous devez vérifier ce que disent vos interlocuteur ainsi que vos propres idées avant de vous exprimer, et ne pas vous reposer sur ce que vous croyez savoir. Si j'ai pris cette peine, c'est avant tout par respect parce que même si je n'étais pas d'accord, il fallait que je vous écoute et que je tienne compte de vos idées. Et sur certains points j'ai donc pu constater que vous avez raison, comme pour l'utilisation excessive des @.
A propos de la lisibilité du code :
J'ai une écriture bien à moi et ceci depuis que j'ai écrit des librairies C++ assez particulières comportant des mégaoctets de codes et des lignes par dizaines de milliers. Avec les conventions établies je n'aurais jamais pu mener à terme ce projet et j'ai été amené à prendre certaines décisions que je n'aurai pas adoptées dans d'autres cas, comme écrire des lignes dont la taille faisait plusieurs largeurs d'écran. Ceci dit je suis capable de me plier à n'importe quelles conventions pour peu qu'on me le demande, et je n'aurais jamais dû envoyer une source sans me conformer à ce qui se fait habituellement. Cette source est juste reprise des mes travaux habituels que je suis le seul à utiliser, et que j'ai simplifié à la va-vite pour aider quelqu'un, j'aurais dû penser qu'il était souhaitable de la normaliser.
Vous n'auriez pas dû vous montrer si intransigeants à l'égard de mon code, ma manière de procéder n'engageant que moi. Il n'est certes pas à l'image de ce que vous auriez pu attendre, mais ce n'est pas comme s'il ne marchait ou comportait de réelles failles. S'il est spécial, il reste d'une certaine façon, certes peu habituelle, bien organisé même d'une manière peu conventionnelle, il est stable et fournit des réponses cohérentes. Si vous m'aviez simplement demandé de manière courtoise de les réécrire, ce serait déjà fait.
A propos des "short open tag" :
Si je prétend qu'ils sont plus lisibles, c'est juste parce que mon éditeur de texte les affiche dans une certaine couleur et que ça me permet de faire la différence entre les sélecteurs et l'affichage du coin de l'œil. Mais il est vrai qu'ils n'ont rien à faire dans un code à l'usage de débutants et que s'ils commencent à être désactivés par défaut, c'est qu'ils vont bientôt disparaitre. Je vais les regretter.
Une fois encore j'estime que vous avez été trop durs et ça n'a pas simplifié le débat. Il y a eu une grosse part d'exagération quant à la nuisance à la lisibilité du code par exemple. Ici aussi, un peu de courtoisie aurait contribué à mettre fin à une polémique inutile.
A propos des SELECT * :
J'ai fait des tests de performances et il se trouve que tout sélectionner ou sélectionner nominativement les champs est équivalent pour une table d'environ 20 champs. En dessous, la sélection nominative l'emporte, au dessus, la sélection totale est beaucoup plus performante. Ces différences de performances augmentent significativement avec le nombre d'enregistrements sélectionnés, mais n'a pas l'air de dépendre du nombre d'enregistrements dans la table. Le tout a été testé avec 10k requêtes avec des tables allant jusqu'à 100k enregistrements.
Personne n'avait raison ni tort au sujet des performances, mais je peux adhérer facilement au fait de préférer nommer tous les champs utilisés. Je vais trouver un compromis pour ma source, pour laquelle on se disputait pour une différence de l'ordre de 3 microsecondes.
A propos de l'@ :
Les tests de performances réalisés montrent que, en cas d'erreur, l'@ peut augmenter jusqu'à 1200% le temps d'exécution d'une instruction. Il ne faut donc l'utiliser que si l'erreur attendue est exceptionnelle, avec le plus de parcimonie possible. Il vaut mieux effectuer des vérifications sous forme de conditions que d'empêcher des erreurs de s'afficher quand c'est possible.
Pour le mysql_query, je persiste à dire que j'ai effectué avant les vérifications nécessaires à un bon déroulement sans erreur PHP. Si quelqu'un pense à une erreur que je n'ai pas prévu et qui est susceptible de valoir la peine d'être anticipée, qu'il m'en fasse part. Personnellement, j'ai testé de mettre n'importe quoi en guise de requête et le PHP ne génère pas d'erreur sur ma machine ou celle de mes hébergements, même en mode E_ALL.
A propos des sessions :
Je pense qu'il vaut mieux relire les tables sur chaque page pour une meilleure actualisation des données, comme un bannissement ou les privilèges accordés à l'utilisateur qui doivent être effectifs dès modification, ce qui ne serait pas le cas en stockant les informations dans la session. Je peux m'arranger pour que mon script soit configurable en ce sens, pour laisser le choix entre les deux systèmes, et que l'on se passe par défaut de la table session.
A propos des return :
Leur utilisation est correcte et a sa logique, car ils permettent de renvoyer le résultat d'un script tout en terminant le système d'identification quand il a échoué et que cela ne sert plus à rien de continuer au risque de provoquer des erreurs, mais je vais dorénavant me contenter de solutions plus standards puisqu'elles n'ont pas l'air de vous plaire et qu'elles peuvent déstabiliser le lecteur. Je ferai probablement de véritables fonctions au lieu de "scripts-fonctions", que j'utilise occasionnellement depuis que j'ai découvert qu'include pouvait renvoyer une valeur. Cela permettra également que je produise un fichier PHP unique.
A propos des informations de connection :
On me dit que la vérification de l'IP n'est pas très fiable, et j'en conviens. Je ne connais pas grand chose au système d'adressage IP, et si vous me dites qu'une adresse peut être simulée, je vais vous croire sur parole. Toutefois, cela ajoute une vérification supplémentaire qui n'est pas spécialement gourmande en ressources. Pour ne pas avoir à discuter sur un détail aussi trivial, je vais m'arranger pour que cela soit optionnel, et je vous invite à me communiquer des méthodes plus fiables si vous en connaissez.
La méthode qui limite le nombre de tentatives de connection en cas de mauvais mot de passe peut-être une bonne idée. Une autre idée est un système anti-flood pour limiter le nombre de tentatives et donc ralentir de manière suffisamment significative la méthode qui consiste à tester toutes le combinaisons une par une au point de la rendre inintéressante. Toutefois, j'aborderai ces solutions dans une version ultérieure.
A propos du fichier 'securite.php' :
Effectivement, j'ai oublié de vérifier la présence des variables que je tente de supprimer et c'est une erreur grossière de ma part. Merci kankrelune de l'avoir remarqué.
Voila pour l'essentiel, il me semble que comme remise en question sérieuse, cela devrait faire l'affaire. Je reconnais mes erreurs et j'agirai en conséquence, notamment en réécrivant ma source d'ici quelques jours. J'espère que vous en ferez autant, mais je n'exige rien car ma priorité sera désormais d'avoir des échanges efficaces avec un comportement digne d'un professionnel qui se soucie plus de l'efficacité de son équipe que de ses opinions personnelles. En tout cas, je m'excuse de ne pas avoir vu les choses sous cet angle plus tôt.
J'espère que nous aurons des meilleures relations à l'avenir.
3 juil. 2008 à 08:45
Juste un petit truc... elle sert à quoi la table session... .. ?
@ tchaOo°
2 juil. 2008 à 22:15
là, je suis carrément sur le cul après avoir lu les commentaires, puis le code. Il y a certaines affirmations qui me laissent perplexes, d'autres qui me font réfléchir.
Farfadh, j'ai lu ton code. Nous n'avons visiblement pas la même notion de la lisibilité d'un code, ou, puisque tu en fais mention, de le façon de développer dans le monde réel (moi, mon monde réel, c'est l'entreprise). Pourquoi ? Je m'explique...
Les commentaires et points étant nombreux, je vais sans doute faire ça en vrac.
- Selon moi, tu as bien trop de fichiers pour ce que ton code fait. Pourquoi faire ? Je ne vois pas en quoi ce serait plus lisible ainsi; ça l'est si chaque fichier a un rôle distinct. Ce n'est pas le cas ici.
- html/php/mélanges et ratatouille... : non sérieux...séparer les couches, c'est quand même mieux et nettement plus lisible. Et là, je parle en professionnel : le code spaghettis bolognaises, c'est anti-perf, anti-évoluttion, et anti-thunes du coup. Tu veux un exemple de séparation ? http://www.phpcs.com/codes/PHP-PHOTOPHOP-PHPDRAW_44762.aspx Vas-y, lâche-toi. Et ce code est bien plus complexe que le tien. Si avec un code aussi simple, tu mets autant de bordel, tu fais quoi sur de gros projets...? Et par gros projet, je n'entends pas le code que je te montre en exemple, qui est minuscule...je te parle d'un vrai gros applicatif web musclé et velu. Il faut vraiment que tu m'expliques en quoi ton code est lisible ? Ce n'est pas difficile de séparer le html du php (parfois si...hein...mais globalement, non).
- les short tags : tu parles de perf et de lisibilité : question lisibilité, foutaise...c'est juste une question d'habitude. Par contre, c'est voué à disparaître, et c'est supporté par de moins en moins de serveur. Et c'st totalement incompatible avec le xhtml. Alors moi, grand débutant, si je veux utiliser ton code mais que je veux aussi utiliser du xml/xhtml, je fais comment ? Je me tape chaque short tags pour les modifier? Franchement...si tu offres ton code...pourquoi imposer des normes révolues aux autres et les forcer à modifier ton code pour pouvoir l'utiliser ? Et c'est valable pour ton html : les standards, les évolutions, c'est pas pour emmerder le codeur web de base...c'est à la base une intention louable : la portabilité, l'accessibilité. S'ouvrir au plus grand nombre. C'est pas ce que tu veux faire en postant ton code ici...? Parce que ce n'est pas ce que tu montres DANS ton ode, ce serait plutôt : je code à l'arrache, comme je le veux, et je voçus emmerde. Sérieux. C'est comme ça que je le ressens après avoir lu ton code, et tes réponses. Sauf que dans ce cas, ton code, garde-toi le...non ?
- @ et consorts : je te cite : "Le @ est inutile car il n'y a aucune possibilité d'erreur sur ces commandes. Sinon, je pourrais en mettre sur toutes les lignes du code." Ah? Merde...moi qui fait depuis des années if(!@myFunc()) {throw new Exception(...);}, je serais dans l'erreur ? C'est impossible? On ne peut pas contrôler le retour de fonctions/méthodes préfixées par un @ en php? 'tain, on en apprend tous les jours. Bref : c'est ta façon de réponre, affirmative et confiante, qui m'a fait sourire. C'est une absurdité, ce que tu as écrit. C'est pas grave hein...quand on le dit avec un peu d'humilité. Même si perso, hein, je me mets en error_display à Off et que j'ai un gestionnaire d'erreurs perso. Donc je n'utilise que rarement @. Il n'empêche...ton affirmation étais erronée.
- SELET * : T'as enseigné les MCD/MLD et tu dis que SELECT * est préférable quand on a peu de résultats ? Ah. Je n'ai pas enseigné, mais j'ai plus de 10 ans de métier, et mon expérience m'a montré le contraire. Prouve-le donc ? Tu ne trouveras aucune doc technique appuyant tes dires. Et j'ai comme dans l'idée que des concepteurs de moteurs de BDD savent de quoi ils parlent quand ils écrivent la doc technique de LEUR logiciel. De même que l'expérience terrain me semble assez sûre...Mais bon...t'as été prof...t'as sûrement raison. Ah et puis, les champs ajoutés...ouais...et pour les INSERT ? Tu fais comment ? Tu_ vas me dire : INSERT INTO table VALUES (champs...), sauf que si l'ordre change, t'es grave dans la merde. Et puis une requête SELECT avec les champs nommés, c'est quand même bien plus lisible (puisque c'est un maître mot chez toi) qu'un SELECT *, non ? Au moins, tu SAIS ce que va chercher la requête. Et elle va chercher ce dont elle a besoin, donc tu SAIS un peu mieux ce que va faire le code derrière. Tes arguments ne sont pas défendables, sincèrement.
- Ah, je reviens sur les short open tags et le <?= bla bla parce que c'est plus rapide. Et alors ? Je préfère perdre 1ms sur un code, mais gagner 1 semaine dans le cadre de l'évolution d'un projet. Ca, c'est le monde réel. De plus, je n'ai pas du tout du tout les mêmes résultats que toi : du html pur reste plus rapide -selon MES tests hein...- que du echo...mais bon.Ca reste tellement infimes ces optimisations dans la plupart des projets, même gros...là, l'important, c'est la "scalability".
- Je suis plutôt d'accord avec toi concernant le MVC. Bah ouais, comme quoi...:-) Mais ça n'empêche pas de coder de manière organisée et structurée...et lisible. Et logique. Et ça n'empêche absolument pas de séparer le html du php de toute manière.
Chais pas...t'as l'air intelligent, Farfadh, alors stp, lis des codes de Neige, de Kankrelune, de moi...et réfléchis 30 secondes. On sent qu'il y a de l'organisation dans ton code, dans ta façon de l'écrire...mais je t'assure, pour moi, il y a de grosses incohérences et d'énormes aberrations. Mais ce n'est pas grave...il faut juste savoir se remettre en question parfois.
2 juil. 2008 à 15:20
Le plus drôle je trouve c'est que tu ne vois pas l'intérêt d'utiliser le modèle mvc mais au final tu l'utilise quand même puisque ta vue est séparée du modèle... après tel quel ton contrôleur est mélangé à ta vue mais ça reste du mvc... sauf que tu utilise la méthode pull au lieu de la méthode push... faudra revoir la définition de mvc... .. .
Pour le SELECT * re lol... revois la façon de fonctionner d'une SGDB, refait tes bench et on en reparle... je travail (pour un FAI) sur des bdd avec plusieurs centaines de miliers d'entrées... je t'explique pas la gueule des serveurs si je fais un SELECT * pour récupérer, par exemple, la liste des abonnés... lol... .. .
Sur ce comme Neige je ne vois pas l'intérêt d'essayer d'échanger de manière constructive avec quelqu'un qui, sous couvert de poster son code pour avoir l'avis des autres, veut en fait seulement qu'on lui dise que son code est top et sans aucune erreur alors que ce n'est pas le cas... .. .
Bonne continuation
@ tchaOo°
2 juil. 2008 à 14:37
Sans vouloir te vexer ta remarque sur tes amis est totalement déplacée et n'est pas vraiment constructive...
2 juil. 2008 à 14:24
Je ne sais pas pourquoi tu me parles de MLD, alors que je n'ai fait aucune allusion à la gestion de tes données (je n'ai même pas regardé la structure de la table).
Pour ma part, je n'insisterai pas, puisque la communication semble hermétique entre nous.
Cela dit, je suis ravi d'avoir permis à tes collègues de rire, puisque mes blagues pourries ne font pas rire les miens.
Quant à l'application du modèle MVC aux applications web, je suis navré, mais en ce qui me concerne (et je sais que je ne suis pas le seul à défendre ce point de vue) c'est assez flagrant.
En PHP 5 Orienté Objet, le modèle, concrètement, ce sera l'ensemble de classes. Le contrôleur sera généralement les scripts appelés directement par le client. Quant à la vue, ce sera généralement un système de templates, ou quelque chose qui fait (à peu de choses près) le même travail.
Je ne vois donc pas en quoi ce n'est pas applicable au web...
Mais là encore, ce peut être un grand débat et CS n'est pas l'endroit idéal pour ça.
Juste un dernier truc : pour pas revenir sur le fil où on s'est croisés la première fois... Les sessions ont été introduites en PHP4, je ne vois donc pas comment, avant PHP3, les variables de sessions pouvaient être passées dans des cookies... Si c'était le cas, c'était le fait d'un mauvais développeur, nullement de PHP lui-même.
Bonne journée, j'espère faire rire encore tes collègues (on peut s'arranger si tu veux que je fasse un spectacle Live sur scène)
2 juil. 2008 à 14:09
2. J'utilisais le 'short open tag' pour une raison de performances et de lisibilité. Mais il est vrai que j'aurais pu m'en passer. Mais bon, j'en parle dans le manuel alors ça ne devrait pas poser de problème. Ce que je reprocherais à mon système, ce serait plutôt d'avoir un peu mal organisé mes include.
4. Je voulais qu'il soit le plus léger possible. Juste le strict nécessaire pour tester le système d'identification.
5. Le @ est inutile car il n'y a aucune possibilité d'erreur sur ces commandes. Sinon, je pourrais en mettre sur toutes les lignes du code.
6. Dans la majeure partie de mes sites, ce SELECT * s'est révélé utile. De toute manière il ne s'agit que d'un enregistrement au plus, donc pas de gros travail pour MySQL, peu de données qui transitent et à stocker dans PHP. Cela ne mérite pas qu'on lance une conversation dessus.
Simple, en terme de temps d'exécution : "1000 instructions" < "1000 instructions + 100".
Pour en revenir au modèle MVC, son défaut le plus connu est de ne pas bien s'adapter aux solutions Web, parce qu'il n'est pas prévu pour un fonctionnement synchrone. Pour le coup la partie contrôleur est répartie à plusieurs endroit du script :
- Au tout début du traitement, elle va sélectionner le modèle à utiliser, mais une partie du modèle est toujours chargée quoi qu'il arrive, et c'est le cas d'ailleurs pour le système d'identification, entre autres. Effectivement, ce dernier doit bien entendu assumer une charge de la partie modèle en préparant les données liées à l'utilisateur, mais du même coup va changer un petit peu le contenu des pages sans toutefois nécessiter d'appeler une vue particulière.
- Le modèle appelé va déterminer une vue à utiliser par défaut mais qui est susceptible de changer selon les résultats du traitement. Toutes les pages ayant des structures communes, c'est le fichier principal des vues qui va être amené à sélectionner une vue ou une autre pour boucher les trous.
- La vue appelée effectue des sélections mineures qui peuvent déterminer par exemple si on doit afficher une liste de résultats, une erreur ou une alerte d'absence de résultats. Parfois cette sélection se borne à afficher ou cacher une partie d'une page, ou de choisir un fichier à inclure, Mais comme c'est une petite partie de la vue qui change et que le reste est une partie commune aux différents affichage, c'est cette vue qui va effectuer cette sélection finale.
Dans le cas du système d'identification, le contrôleur est quasiment inexistant. C'est le modèle qui prend son travail en charge pour déterminer si on a une erreur critique, une impossibilité de calculer les données. Or, comme il s'agit d'un semblant de gestionnaire d'erreur, il est partout là où on peut en avoir une et il est impossible de le séparer du reste. Et c'est la vue qui va déterminer quelle type de contenu va être affiché avec un minimum de contrôle de sélection. En tout cas la partie contrôle est tellement faible qu'il serait ridicule d'essayer de la traiter ailleurs.
Quoi qu'il en soit, ce système d'identification s'est toujours parfaitement bien intégré à mes sites parce que au final, le modèle MVC ne s'applique pas à lui. Il ne fait que du modèle, recevant des données pour en ressortir d'autres. A aucun moment il ne décide d'autres modèles à charger, ni de vues à utiliser. Il ne fait que préparer les données nécessaires à ces tâches, toutes deux réalisées dans index.php par ailleurs.
2 juil. 2008 à 13:18
@ tchaOo°
2 juil. 2008 à 13:16
- Pour ce qui est du short tag il ne faut effectivement pas l'utiliser... ou alors il ne faut pas qualifier son script de portable short_open_tag étant désactivé sur bon nombre de serveurs... qui plus est c'est plus clair d'utiliser <?php lorsque tu mélange plusieurs langage de prog dans une même page... je reprend souvent l'exemple suivant... <? = "je vais parler" et <?php "je vais parler php"... pareil pour le <?= à remplacer par <?php echo
- Pour ce qui est de passer de php à html il n'y a pas à proprement parlé de perte de perf car la perte dû au passage de l'interpréteur php au html est en partie compensée par l'économie d'echo() et autre print()
- Pour ce qui est du SELECT * j'aurais tendance à rejoindre Neige... la perte de perf est très importante avec les * car ta SGDB avant de te renvoyer tous tes champs doit d'abord faire une recherche en interne sur la structure de ta table pour connaitre les champs de cette dernière... mieux vaut entrer tous les champs en clair dans ta requête quitte à ce que la liste soit longue...
- pour ce qui est de la gestion des erreurs php et la récupération des données soumises excuse moi mais c'est crade...
mysql_real_escape_string(@$_POST['pseudo'],$sql_CONNECTION);
Ô_o
tu fais un escape string sans savoir ce que contient ta variable et sans même savoir si elle est instanciée... les @ c'est bien... en abuser ça craint... .. . ;o)
- pourquoi tu n'utilise pas les sessions ? dans ton fichier session.php tu lance les session php puis tu ne les utilises pas... quel intérêt
$session_UTILISATEUR ça serait pas plutôt $_SESSION['UTILISATEUR'] que tu voulais faire... .. ?
- je ne trouve pas non plus très propre d'utiliser des return dans ton script lorsque l'auth échoue ou est déjà faite... tu coupe l'exécution de ton script c'est pas très logique... tu met tes include dans des block de conditions qui sont vide je n'en vois pas l'intérêt c'est à mon avis une erreur de conception
- Maintenant pour ce qui est de la sécurité... toujours en rapport avec les session il pourrait être bien de coupler l'id de session à un id spécifique à l'internaute pour éviter les vols de session... tu récupère la soit disante adresse ip de l'utilisateur via $_SERVER['REMOTE_ADDR'] cette variable est très facilement falsifiable notamment en passant par un proxy... la méthode pour (essayer de) récupérer une adresse ip ""fiable"" est un peu plus compliquée tu pourra trouver une piste sur phpcs... personnellement j'aurais tendance à ajouter un système anti brute force (3 tentative de connexion puis ban de 20 ou 30 min si echec) contre les bot ou les softs de brute force... pour ce qui est du cryptage j'aurais tendance à plutôt passer par un haschage lors de l'insertion en bdd c'est plus sécurisé mais bien entendu il est impossible de retrouver le mdp de l'utilisateur s'il l'a oublié dans ce cas il faut en générer un nouveau... personellement je hash avec un grain de sel le mdp soumis par l'utilisateur lors de la soumission du formulaire d'identification de sorte que le mdp soumis ne transite pas en clair... mais ça c'est un détail... .. .
Voili voilou... .. .
@ tchaOo°
2 juil. 2008 à 11:08
1. Pour la séparation PHP / HTML, je persiste. Tu n'as pas compris. Manifestement, le modèle MVC t'es totalement étranger. C'est pas grave, c'est le cas de beaucoup éveloppeurs. Ton script fait tout : modèle, vue et contrôleur. Et ça, c'est pas facilement maintenable, évolutif et intégrable.
2. Je soulignais juste que le code n'est pas facilement portable et peut nécessiter des modifications dans la config. Je voulaid donc juste signaler que, d'une manière générale, quand on publie un code source, on prend (mais c'est une manière de faire propre à chacun) la précaution de s'assurer que le code sera facilement utilisable dans toutes les configurations, sans modifications. En l'occurrence, les short tags dépendant de la configuration, je signalais simplement qu'il était préférable de ne pas les utiliser.
3. Je reconnais que j'ai peut-être sorti ça de nulle part.
4. Ton code HTML, s'il est un exemple, est donc un mauvais exemple. Je préfère (et je ne suis pas le seul) les sources avec de bons exemples que celles avec un mauvais exemple. Je sais pertinament que la plupart des utilisateurs se contentent de pomper sans comprendre et sans modifier (j'ai bein dit : "la plupart"). Pour cette raison, un code HTML valide (même 4.01 Transitionnal) aurait été judicieux (mais là encore, c'est juste mon point de vue à moi)
5. Le @ empêche l'interception des erreurs, mais puisque tu testes la réussite ou l'échec de la requête pour afficher un message d'erreur en conséquence, ce n'est pas une mauvaise chose de le mettre. Le @ n'empêche pas de vérifier que la fonction a bien réussi (on peut tester sa valeur de retour, encore heureux). Mais c'est tout un débat, et malheureusement PHPCS ne permet pas d'en avoir... Dommage, parce que la gestion des erreurs est selon moi, un sujet très intéressant.
6. Quant au select * j'ai un doute, mais bon.
Pour ce qui est du manuel, effectivement, je ne suis pas allé lire. Je n'ai d'ailleurs pas prétendu avoir lu toute la source en détails. J'ai juste lancé quelques remarques en vrac.
Désolé que tu aies passé autant de temps à tester ces perfs... Je pense que tu peux en faire un article quelque part, parce que c'est quand même intéressant.
"par exemple PHP peut apparemment mettre moins de temps à exécuter 1000 instructions echo('texte'); qu'exactement la même chose avec en plus 100 instructions echo($_SERVER['SERVER_NAME']); , ce que je ne parviens pas à expliquer."
=> J'ai pas bien compris... Moi, ça me parait logique, à première vue... Mais comme j'ai pas bien compris, je me plante peut-être...
2 juil. 2008 à 02:10
"Voila le test que j'ai réalisé : 100 inclusions d'un script qui écrit dans la sortie standard 100k caractères fixes et 100 variables, avec plusieurs méthodes avec la description du script (qui est répété donc 100 fois) et dont voici le classement par temps d'exécution (moyenne sur 20 exécutions, le serveur apache est relancé après chaque méthode)"
Et ne pas tenir compte d'une mention au milieu qui aurait voulu que "le tout (soit) répété 100 fois".
Je m'excuse pour cette coquille et pour ne pas m'être relu correctement.
2 juil. 2008 à 00:07
Voila le test que j'ai réalisé : 100 inclusions d'un script qui écrit dans la sortie standard 100k caractères fixes et 100 variables, le tout répété 100 fois, avec plusieurs méthodes avec la description du script (qui est répété donc 100 fois) et dont voici le classement par temps d'exécution (moyenne sur 20 exécutions, le serveur apache est relancé après chaque méthode) :
- Top 1 : environ 840ms : 1100 balises PHP 'short open tag' contenant chacune soit une chaîne de caractères fixes délimitées par des apostrophes, soit une variable.
- Top 2 : environ 870ms : une seule balise PHP, caractères fixes dans des chaînes délimitées par des apostrophes, toutes les sorties sont font au moyen de la commande echo (note : pour prend 400ms de plus quand on enlève les 100 commandes echo qui affichent les variables).
- Top 3 : environ 900ms : même test mais les chaînes sont délimitées par des guillemets (note : prend 400ms de plus quand on enlève les 100 commandes echo qui affichent les variables).
- Top 4 : environ 910ms : 1100 balises PHP standard contenant chacune soit une chaîne de caractères fixes délimitées par des apostrophes, soit une variable.
- Top 5 : environ 1090ms : les caractères fixes sont hors des balises PHP, chaque variable est affichée au moyen d'une commande echo placée dans une balise PHP standard (note : prend autant de temps quand on enlève la totalité des balises PHP)
- Top 6 : environ 1090ms : même test mais avec des balises "short open tag" (note : prend autant de temps quand on enlève la totalité des balises)
- Top 7 : environ 1640ms : une seule balise PHP, tout est affiché au moyen d'une unique commande echo avec concaténation des chaînes et des variables (prend 100ms de plus quand on ne concatène plus les variables)
J'ai refait tout le test depuis le début plusieurs fois et j'obtiens le même résultat. Donc, conclusions de ces tests pour optimiser les performances d'un script :
- le code HTML devrait être écrit intégralement par des echos, jamais hors des balises PHP. Je sais, vous allez me dire, comment est-ce possible que le PHP puisse prendre plus de temps à exécuter du code qu'à recopier bêtement un fichier ? La réponse m'échappe complètement, il faut croire que le moteur du PHP est particulièrement mal optimisé et que le texte trouvé hors des balises transite par des méthodes aberrantes avant d'atteindre la sortie standard.
- il est préférable d'utiliser des apostophes plutôt que des guillemets pour délimiter une chaîne, mais la différence de performance n'est que de l'ordre de 3,6%.
- la concaténation des textes est trop laborieuse et devrait être évitée au possible.
- il est préférable d'utiliser des multitudes de balises PHP avec peu de code qu'une seule avec beaucoup de code, mais la différence de performance n'est que de l'ordre de 3,6%.
- il est préférable d'utiliser des PHP 'short open tag' que standard, mais la différence, de performance n'est que de l'ordre de 8,3% (note : les méthodes top1/top4 engendrent le calcul de 110k balises PHP sans caractères en dehors, alors que les top5/top6 seulement 10k de balises avec 1M de caractères en dehors, ce qui explique que ces dernières ne sont pas affectées de manière significative par la différence des balises)
Toutefois, ce ne sont pas des lois, mais de simples constatations. Les tests sont trop peu concluants, pas forcément bien adaptés et présentent des données pour le moins étranges.
Maintenant, neigedhiver, à nous deux. Si je suis toujours ouvert au débat, je n'apprécie jamais les gens qui donnent une opinion sans pouvoir la justifier. Maintenant tu vas m'expliquer ce qui te permet d'affirmer devant tout le monde pour critiquer la source que je met gentillement à disposition, que la "multitude" de balises PHP ralentit l'exécution de mon script. Je viens de passer plus de deux heures à faire ces tests pour vérifier ce que tu disais et ne pas me contenter de te contredire avec mes opinions personnelles comme tu le fais avec moi.
Mais au vu nos précédentes conversations tu as perdu toute crédibilité. Alors je n'accepterai de réponses que solidement argumentées, appuyées par des sources ou de solides démonstrations. Ne me fais pas perdre mon temps avec des idées reçues qui ne sont d'ailleurs même pas forcément de toi.
D'avance, merci, autant pour la communauté que pour moi.
1 juil. 2008 à 21:18
1. Je ne mélange pas HTML et PHP autant que tu veux bien l'entendre. Tous les traitements sont effectués avant écriture, la partie traitement est d'autant plus clairement séparée du code HTML que c'est signalé dans les commentaires. Ce qui reste en PHP n'est presque que de du "short tag" spécialement fait pour, ou du conditionnel pour sélectionner la sortie, et de toute façon chacun de ces mini-blocs PHP ne contient qu'une unique variable et contient au plus 48 caractères. Ce n'est pas en aucun cas un code HTML définitif, tu auras remarqué à quel point il est laid. C'est un exemple d'utilisation, les véritables scripts sont dans des include, les pages HTML à produire sont à la charge du développeur du site.
2. Ce problème est signalé explicitement dans le manuel dans la procédure d'installation et de configuration. Moi je procède ainsi parce que ces "short tags" signalent de manière lisible qu'il ne s'agit que d'une insertion de données dans la sortie, mais c'est un choix personnel auquel je ne demande à personne d'adhérer. Le changement que tu suggères est également dans le manuel pour ceux qui ne pourraient pas ou ne voudraient pas changer la configuration de leur PHP.
3. Je ne sais pas grand chose de ces performances, si ce n'est que cela n'a jamais posé problème pour des sites visités des milliers de fois par jours et donc génèrent des dizaines de milliers de pages par jour. Ça a le mérite de laisser un code lisible et donc très facilement modifiable. Mais encore une fois, je fournis un code PHP, le code HTML étant fourni en exemple et parfaitement lisible par la totalité des navigateurs qui existent. Je vais vérifier ce que tu affirmes, car cela m'étonnerai vraiment que faire quelques insertions dans la sortie dans un page conséquente soit plus lourd qu'une unique balise PHP dans laquelle se trouve des kilooctets entiers en chaîne de caractères qui doivent ensuite passés à la au mot-clé echo, et de passer par le buffer de sortie avant d'être finalement envoyé au navigateur du client.
4. Le code HTML est un exemple. Tu ne crois quand même pas que je fais des sites aussi laids ? Sache que tous mes sites finis passent la validation w3 sans la moindre alerte. J'ai simplement eu la politesse de ne pas surcharger ce code produit à titre d'exemple.
5. Le error_reporting doit être correctement configuré en ligne, ou bien un gestionnaire d'erreur personnalisé doit être mis en place. Si je ne met pas de @, c'est parce que ça rend l'interception d'erreur impossible et qu'à ce moment là, il est impossible de les loguer à l'attention des débugueurs qui doivent passer après. Sinon en cas d'échec de la requête, aucun message d'erreur n'est affiché, et n'est récupérable que via la fonction mysql_error. Ce n'est le cas que si aucune connection n'est ouverte, ou qu'on lui fournit un mauvais identifiant de connection, ce qui est une totale impossibilité dans mon code. Donc la faille dont tu parles n'existe pas, se référer au manuel pour comprendre comment tout ça marche.
6. Le SELECT * est parfaitement adapté dans cette situation. Effectivement on va rajouter des champs dedans parce que je n'ai mis là que ce qui est nécessaire à l'identification. Et donc quand ce sera le cas, on disposera de toutes les informations sur l'utilisateur que l'on va probablement réutiliser par la suite sans devoir faire de nouvelle requête. D'ailleurs, niveau performance, il est préférable de sélectionner tous les champs quand on travaille sur un nombre très limité d'enregistrements, plutôt que d'en exclure un ou deux en donnant à MySQL la charge de lire un par un tous les champs que l'on souhaite obtenir. Encore une fois, consulter le manuel à propos des variables du système d'identification mis à la disposition du développeur.
Quand j'ai dit que j'encourageais les critiques, je parlais bien évidemment de requêtes constructives. Vos opinions n'intéressent personne si vous n'êtes pas capables de les justifier par un argumentaire ou des sources fiables. Dis-moi ce qui n'est pas sécurisé à ton avis et ce que tu suggères en appuyant tes choix, et je ferai une nouvelle version en un rien de temps. Parce que sinon je n'aime pas être décrédibilisé pour pas une cacahouète.
1 juil. 2008 à 18:37
Voici quelques commentaires en vrac :
- tu mélanges PHP et HTML : c'est mal. Mieux vaut séparer le contrôleur de la vue, c'est plus facile à maintenir et à intégrer
- tu utilises des shorts tags, c'est mal : ta configuration les autorises, pas toutes. Ce n'est donc pas compatible partout. Mieux vaut utiliser des tags standards <?php et un echo plutôt que <?=
- tu ne cesses d'ouvrir et fermer des balises PHP. C'est mal : tu perds en performances, PHP prenant un coup la main, la laissant pour quelques caractères blancs (tabs, nl, espaces), puis la reprenant.
- ton HTML n'est conforme à rien : même pas du HTML 1. Pas de DTD, le navigateur ne sait pas à quoi s'en tenir.
- tu ne fais pas de contrôle d'erreurs corrects lors de l'exécution de tes requêtes SQL. Probablement que ta configuration est laxiste. Avec error_reporting(E_ALL), certaines erreurs pourraient s'afficher. Puisque tu vérifies qu'une requête s'est bien exécutée, autant masquer l'erreur avec un @ c'est pas très propre, mais au moins, l'erreur PHP n'est pas affichée, au profit de la tienne (le mieux étant un gestionnaire d'erreurs appelé avec trigger_error() ). Notamment ici :
if(!$session_RESULTAT= mysql_query($session_REQUETE, $sql_CONNECTION)) // en cas d'echec de la requete
Si la requête échoue effectivement, un méchant message d'erreur va s'afficher.
- SELECT * : c'est mal. Si la table évolue et qu'on y rajoute des champs, ils seront récupérés également, alors qu'ils seront probablement inutiles pour l'identification (on n'a besoin que du login, de l'id, et du mot de passe, éventuellement le statut utilisateur, le user_level... mais le reste, on s'en cogne)
- tu prends garde de supprimer quelques variables dans securite.php, mais tu définies le mot de passe de la base de données dans une constante... qui ne pourra pas être supprimée... C'est pas cohérent.
J'arrête là, ça devrait aller...
Cela dit, ton système d'identification ne me parait pas être franchement hors du commun ou particulièrement sécurisé... Mais c'est que mon avis perso.