Après les dernières mises à jour de Firefox, tout se met à ne plus parcher : j'ai des caractères exotiques qui apparaissent là où il n'y en avait pas avant.
Comme je viens de galérer grave pour installer Wampserver sur un nouveau serveur Windows 2008, je pensais que ça venait de là, mais ça n'a pas l'ai.
A cause des incompatibilités avec W2008, mon Wampserver est en version 2.2.21, PHP en 5.3.8 et MySQL en 5.5.16, et j'ai Firefox en 46.0.1.
A l'entrée de mon site (index.php), j'ai un formulaire avec "method='POST'", dans lequel je rentre deux chaînes de carcatères. Le "action=" est un autre module php qui m'imprime à l'écran les chaînes en question : c'est là qu'apparaissent les caractères exotiques (vous savez, par exemple les points d'interrogation dans un losange...)
J'ai l'impression d'avoir tout essayé dans les fichiers de configuration de wampserver et/ou dans les en-tête http, ou les header PHP : rien n'y fait !
J'ai lu plusieurs interventions d'Otomatic sur ce sujet, mais je n'ai pas trouvé de solution.
Alors j'appelle au secours. Et avec tout ça j'ai passé quatre jours a me débattre avec des problèmes qui ne devraient pas être : je craaaaaaaaaaaaque !
? dans un losange est un caractère non reconnu comme étant utf-8, a prioti affichage de caractères iso-8859-1 dans un environnement déclaré utf-8.
Ça n'a rien à voir avec Wampserver. Il n'y a aucune modification à faire dans la configuration Apache.
Il faut simplement que les jeux de caractères utilisées soit les mêmes de bout en bout.
Si la page du site est déclarée utf-8 (Attention, le header php est prioritaire sur les déclarations <meta), il faut que les transactions entre la base de données et php le soient aussi.
Je suis en utf-8 partout (MySQL et HTML). Je désire bidouiller quelques chaînes de caractères pour les rendre illisibles. Pour cela, avant, j'utilisais mysql_query("select encode('$ma_chaine','mon_salt'). et la même avec mysql decode, sachant que 'ma_chaine' venait d'un formulaire HTML. Maintenant, ça ne marche plus. Je suppose que l'encodage utf-8 interfère. Peut-être qu'il faudrait mettre des utF8_decode ici ou là, mais justement, où ?
Si tu expliquais exactement le but de l'opération, on pourrait peut-être trouver une solution. Et, avec un exemple, ça n'en serait que mieux. Parce que là, c'est quelque peu nébuleux.
Mon site s'ouvre sur une page où s'affiche un <formW> qui demande un nom d'utilisateur et un mot de passe.
L'<action> de ce <form> renvoie à un module PHP où le nom et le mot de passe sont confrontés à la base de données MySQL. En cas de concordance, ils sont encodés à l'aide de l'instruction MySQL "ENCODE(variable,'clé')" (est-ce assez clair ?) et rangés dans deux variables $_SESSION PHP.
La vérification de ces deux variables est faite dans une fonction dénommée "include.php" qui est systématiquement"INCLUDE" en tête de chaque module PHP. Cette vérification effectue un "DECODE(variable, 'clé'), et confronte le résultat à la données. (Je ne suis pas assez pointu pour faire une analyse critique de cette stratégie, je ne sais pas assez bien comment les pirates peuvent se glisser dans un site).
Avant que je ne passe à un codage systématique et attentif en UTF-8, cela fonctionnait à ma satisfaction (c'est à dire que je ne sais absolument pas si ni comment j'étais protégé des pirates, mais mes utilisateurs pouvaient se connecter). Maintenant, la séquence DECODE(ENCODE(nom,'clé),'clé') ne donne plus le nom. C'est ça le problème.
Excuse-moi de ne pas publier le code, j'ai un peu de réticences. Mes explications me semblent compréhensibles. Le sont-elles pour toi ?
La presque totalité des formulaires de connexion avec nom d'utilisateur et mot de passe utilisent le hachage du mot de passe par MD5 (ou plus complexe). À la première inscription (où lors du changement de mot de passe) le résultat de hachage MD5 de celui-ci : $resultat = md5($password) par exemple pour le mot de passe apple on obtient 1f3870be274f6c49b3e31a0c6728957f est enregistré en base de données en tant que tel.
Lors de la demande de connexion, le mot de passe fourni est haché de la même manière et le résultat comparé avec celui stocké en base de données.
Je sais cela. Je suis (presque ?) certain que si j'avais fait ça, le fait de tout passer en UTF-8 m'aurait contraint à redemander un mot de passe à chaque utilisateur.
Mais la raison pour laquelle je m'y étais pris autrement (mais je ne sais pas si elle est bonne) était de refaire la vérification à chaque appel d'une nouvelle page. Et je ne voulais pas manipuler de page en page les textes en clair du nom et du mot de passe.
Cette stratégie me sécurise, et en même temps je ne sais pas à quelle distance cela se trouve du ridicule (genre porte blindée avec 3 serrures, mais clés sous le paillasson).
Quelles sont les mesures préconisées actuellement pour se prémunir des dangers du net ?
> Je sais cela. Je suis (presque ?) certain que si j'avais fait ça, le fait de tout passer en UTF-8 > m'aurait contraint à redemander un mot de passe à chaque utilisateur. Pour se prémunir de tout changement d'environnement du jeu de caractère, il ne faut accepter pour les mots de passe que les caractères ASCII pur, c'est-à-dire : a-z A-Z 0-9 plus quelques caractères comme #[]$*-+ mais de caractères diacritiques comme à é è ç € ù œ
Supposons que le mot de passe soit (sans les guillemets) "ab€defgh" (Troisième caractère étant le symbole de l'euro). Il y a bien huit caractères, mais un seul est hors du domaine 0x21 0x7F, l'euro. Si ce mot de passe a été rentré et validé dans un environnement : - iso-8859-15, il sera codé : 61 62 A4 64 65 66 67 68 - cp-1252, il sera codé : 61 62 80 64 65 66 67 68 - Mac-Roman, il sera codé : 61 62 DB 64 65 66 67 68
Déjà, on peut voir qu'avec trois environnement différents, le même glyphe € sera codé de trois manières différentes, donc trois mots de passe différents avec les mêmes glyphes.
Si on tape ce même mot de passe dans un environnement utf-8, il va être codé, en hexadécimal : 61 62 E2 82 AC 64 65 66 67 68 soit dix octets et non pas huit.
Sera-t-il correctement reconnu quel que soit l'environnement à partir duquel il sera « tapé » ?
> Et je ne voulais pas manipuler de page en page les textes en clair du nom et du mot de passe. Et les cookies ? Y penses-tu ?
> Quelles sont les mesures préconisées actuellement pour se prémunir des dangers du net ? Là, je te renvoie à un article que j'avais écrit pour les pages persos de Free dans la page écrite par Al : [les.pages.perso.chez.free.fr] un article de mon crû : - Quelques notions de sécurité pour les pages dynamiques développées par vous-même
Nota : Les fonctions de cryptage ENCODE et DECODE existent toujours avec MySQL 5.7 mais sont déclarées dépréciées : [dev.mysql.com]