SYSTÈME D'IDENTIFICATION

Commentaire de Farfadh le 01/07/2008 21:18:28

Bien, pas besoin d'être un génie avant de comprendre que tu n'as pas lu le manuel.

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.

Commentaire de Farfadh le 02/07/2008 02:10:08

Une erreur s'est glissée dans la description générale des tests de performances à cause d'une mauvaise édition de ma part. Un script de test est inclus 100 fois, mais ces 100 inclusions ne se produisent qu'une fois, et non pas 100. Il fallait donc comprendre :

"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.

Commentaire de kankrelune le 02/07/2008 13:16:22

je n'ai pas (encore) regardé en détail le code mais je voudrais rebondir sur les commentaires précédents... .. .

- 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°

Commentaire de Farfadh le 02/07/2008 14:09:18

1. MVC/MLD, c'est ce que j'ai enseigné sur le campus il y a quelques années, je le connais suffisamment bien pour dire qu'il ne s'agit seulement d'une théorie pas toujours préférable à l'expérience du terrain, et d'une base sûre pour les développeurs non confirmés. Ton insistance m'épate et a fait mourir de rire mes collègues qui m'ont fait la tronche pendant plusieurs semaines parce que je leur ai imposé de mettre les scripts contenant la partie PHP dans le répertoire 'php' du site, et ce qui génère le contenu HTML dans 'html'. Es-tu en train de me suggérer que je dois en plus mettre le contenu HTML dans des variables pour aller les sortir depuis des scripts dans un dossier 'sortie' ? Je n'y vois aucun avantage qui pourrait me motiver, et encore moins mes collègues : perte de performances, multiplication des fichiers, aucune amélioration de la lisibilité. Pourrais-tu m'envoyer en privé un moyen d'aller voir une de tes sources que je vois de quoi tu veux parler ?

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.

Commentaire de Morphinof le 02/07/2008 14:37:06

Je rebondi sur la remarque "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", heu ah bon? Synchrone ou non le modèle MVC est applicable et maintenant que l'on passe au web 2.0 avec l'ajax il est encore plus d'actualité ^^

Sans vouloir te vexer ta remarque sur tes amis est totalement déplacée et n'est pas vraiment constructive...

Commentaire de malalam le 02/07/2008 22:15:56 administrateur CS

Hello tlm,

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.

Commentaire de Farfadh le 03/07/2008 17:54:36

Stop ! Là je dois mettre un terme à la situation, parce que cette source et ses commentaires, c'est devenu du grand n'importe quoi. J'allais vous répondre un à un avant de me rendre compte que ça ne servait à rien.

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.

Commentaire de kankrelune le 03/07/2008 21:21:28

Tout d'abord je voudrais préciser qu'en aucun cas je garde rancune de la discution ou plutôt de l'échange que l'on a eu... on ne juge pas un homme en un jour... Nous nous sommes tous un peu énervé y compris moi et j'en suis également désolé... c'est malheureusement le lot des discutions écrites par posts interposés... .. .

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)

Commentaire de Farfadh le 03/07/2008 23:55:19

Merci pour le code permettant de contrôler les proxy, ça va m'être utile.

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

Commentaire de kankrelune le 04/07/2008 11:39:24

D'ailleurs au passage la fonction que j'utilise ça donne un truc dans le genre...

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°

Commentaire de malalam le 07/07/2008 19:50:19 administrateur CS

@Jadu : Farfadh a fait amende honorable. Passons donc à autre chose stp.

Commentaire de malalam le 08/07/2008 18:57:51 administrateur CS

En fait, j'y songe :-) Le problème étant que dans ces commentaires parfois un peu acerbes, il y a aussi de vrais réponses, et un débat somme toute intéressant même s'il s'éloigne largement de ce code. Le point de vue de professionnels sur la façon de coder un projet peut intéresser certaines personnes je présume.
Et comme je ne peux pas juste modifier un message...je suis embêté :-)