Discussion :

[DLAWL]

Bonjour,

Pour un code source et des entrants identiques, j'observe une différence de résultat avec la fonction mb_strlen entre PHP 8.2 et PHP 8.3.

En PHP 8.2.14, j'ai loggé les éléments suivants :
mb_internal_encoding() = UTF-8
mb_strlen(c•,¼D•KK“Z`2=�iĉÁ¹óM£) = 20

En PHP 8.3.2 :
mb_internal_encoding() = UTF-8
mb_strlen(c•,¼D•KK“Z`2=�iĉÁ¹óM£) = 24

Dans les deux cas, l'encodage pris en compte est UTF-8. La chaîne est visiblement la même (et de plus, elle est issue de la même donnée entrante et passée par le même code source). Mais, dans un cas, la longueur calculée par mb_strlen est 20 et, dans l'autre, 24.

Je n'arrive pas à déterminer ce qui expliquerait cette différence. Je n'observe pas d'écart de configuration (même version d'Apache 2.4.58.1 dans les deux cas). Rien d'évident non plus dans le changelog des versions PHP.

Le problème se pose dans le cadre d'une vérification de mot de passe qui, par conséquent, ne fonctionne plus en PHP 8.3.2.

Quelqu'un aurait-il une idée sur ce qui peut poser cette situation ? Ou sur les points à vérifier pour identifier cet écart de fonctionnement ?


Merci d'avance.

[unanonyme]

https://github.com/php/php-src/issues/12556 ?

ceci n'est pas vraiment en rapport, mais j'ai trouvé intéressant la partie sur le scrub, et je me suis demandé si ça ne pourrait pas aider, aucune certitude.

https://github.com/php/php-src/issues/13198

Here's another tip: If your application expects to receive UTF-8 text as input, it may be a good idea to check input strings with mb_check_encoding($str, 'UTF-8') before operating on them. If mb_check_encoding shows that the input is not UTF-8, the safest thing to do is to reject it. However, if you want to be more tolerant of unexpected inputs, you could use mb_scrub to sanitize the invalid string. Before calling mb_scrub, you may want to set mb_substitute_character to control what will happen with invalid byte sequences... for example, if you set mb_substitute_character("none"), then the invalid bytes will be deleted from the string, rather than being replaced with "?".

[Pytet]

Bonjour,

A priori le résultat est identique (24) en PHP 8.2.14 et PHP 8.3.1 : https://onlinephp.io/c/b00b4

[DLAWL]

Merci pour vos réponses.

@unanonyme : Merci pour les liens. C'est intéressant et peut-être pas sans rapport. Notamment, cette phrase m'interpelle :

UTF-8 text handling now obeys the W3C specification, and this may result in different output for invalid UTF-8 strings.

Je vais creuser ça.

@Pytet : Oui, j'avais vu sur des sandboxes en ligne que le résultat ne différait pas entre les deux versions. Donc je ne mets pas en cause PHP.
Mais le fait est que j'observe cet écart sur mon projet et que j'aimerais le comprendre. Soit cela vient spécifiquement du fait que je travaille sous OS Windows, soit il y a un paramètre quelque part qui diffère, peut-être lié à l'encodage.

[Pytet]

Tu peux procéder par élimination. Passe ton environnement 8.3.2 en 8.2.14 et refait ton test : tu verras si le problème vient de la version de PHP ou de ton environnement.

Si le problème ne viens pas du changement de version PHP, il semble alors que les chaines comparées via mb_strlen ne soient visiblement pas les mêmes
Difficile de deviner sans plus de détails (tu évoques une vérification de mot de passe, la chaine est récupérée depuis une base de données ? Les 2 environnements PHP se connectent à la même bdd ou 2 SGBD distincts ?)

[DLAWL]

Alors, pour préciser le contexte, je travaille sur un environnement construit avec le logiciel WAMP. Le test est effectivement fait en passant d'une version 8.2.14 à une version 8.3.2 avec les outils de WAMP. Le reste de l'environnement ne change pas : même serveur Apache, même base de données.

Sur le traitement, il s'agit du processus d'authentification. L'utilisateur saisit son mot de passe et le problème se pose pendant la comparaison des hash (hashage de la saisie, comparé avec le hash stocké dans la base de données).

Je saisis le même mot de passe, il passe par le même code source.

La différence de mb_strlen apparaît sur le hash enregistré dans la base de données (si cela peut jouer, celui-ci passe au préalable par un base64_decode). Il s'agit donc de la même chaîne de caractères initiale.

Cette différence est bloquante, car le résultat est utilisé pour le hashage du mot de passe saisi.


Note : Je découvre le processus d'authentification de l'application concernée avec ce problème, car il s'agit d'un aspect historique qui n'a jamais posé de problème jusqu'ici et auquel je n'avais pas encore touché.