Bug #15479
fermé
Impossible de glisser/déposer certains fichiers avec accents (Mac OS uniquement)
0%
Description
Régression apportée par la version 6.4.7
Si on glisse plusieurs fichiers avec accents dans la zone de dépose dédiée à cette effet, soit les publications ne sont pas crées soit elles le sont avec
un encodage incorrect.
Mis à jour par Miguel Moquillon il y a 24 jours
· Edité
MacOS, Windows et GNU/Linux gèrent les caractères accentués UTF-8 différemment en raison des formes de normalisation Unicode : MacOS utilise souvent la forme NFD (décomposée), tandis que Windows et GNU/Linux utilisent généralement la forme NFC (composée), ce qui peut entraîner des incohérences lors de la synchronisation de fichiers contenant des accents ou lorsqu'un client sous MacOS transfert du texte accentué vers un service sous Windows ou GNU/Linux.
Je n'ai pas testé ici mais j'ai déjà eu ce soucis avec des fichiers partagés entre mon vieux Mac et mes portables sous nunux. De visu, les noms de fichiers ou de dossiers avec des accents paraissent correct de part et d'autre mais en fait, sous le capot, l'encodage est différent et les logiciels le voient.
Mis à jour par Miguel Moquillon il y a 24 jours
Si c'est le cas, alors, normalement, le problème devrait exister quelque soit la version de Silverpeas
Mis à jour par Miguel Moquillon il y a 24 jours
- Statut changé de Assigned à Feedback
Mis à jour par Miguel Moquillon il y a 24 jours
· Edité
- Statut changé de Feedback à In progress...
Bon, j'ai demandé à Claude au cas où. Apparemment, il y a bien eu une régression en 6.4.7 avec les corrections de vulnérabilités :
Ce qui a changé en 6.4.7¶
Avant 6.4.7, le JS envoyait X-FULL-PATH: encodeURIComponent(file.fullPath) . L'en-tête ne contenait donc que de l'ASCII, et le serveur faisait URLDecoder.decode(..., UTF-8) dans FileUploadData.from() .
Le commit eaf1608a8a (vulnérabilité #15358) a remplacé ce décodage par Encode.forHtml() côté serveur, ce qui a cassé les noms encodés. C'est la régression #15388.
Le commit 1113f19f3d (correction de #15388) a alors supprimé l'encodage URI côté client. Le JS envoie maintenant le nom brut avec un simple escapeHTML() dans l'en-tête, voir core-war/src/main/webapp/util/javaScript/silverpeas-ddUpload.js:584 et _ silverpeas-fileUpload.js:759_ . Le serveur ne fait plus que StringUtil.normalize() (NFC).
Pourquoi ça ne casse que sur Mac OS¶
Un en-tête HTTP est une chaîne ISO-8859-1. XMLHttpRequest.setRequestHeader() lève une exception dès que la valeur contient un caractère au-delà de U+00FF : TypeError: Failed to execute 'setRequestHeader' on 'XMLHttpRequest': String contains non ISO-8859-1 code point.
Sur Windows et Linux, les noms de fichiers sont en forme NFC : « é » est le seul code point U+00E9, qui passe. Sur Mac OS, le système de fichiers fournit les noms en forme NFD : « é » devient « e » suivi de l'accent combinant U+0301. Ce code point dépasse U+00FF, donc l'exception est levée avant l'envoi. La requête ne part jamais et la publication n'est pas créée. C'est le premier symptôme.
Le second symptôme, l'encodage incorrect, vient du même mécanisme. Quand le nom passe quand même, il est transmis en octets Latin-1 bruts dans l'en-tête, et le décodage côté serveur dépend de la manière dont Undertow interprète ces octets. Je n'ai pas pu vérifier ce point précis. Un test avec un nom contenant « œ » ou « € » devrait aussi échouer sur tous les OS, ce qui confirmerait le diagnostic.
Mis à jour par Miguel Moquillon il y a 24 jours
- Statut changé de In progress... à Closed
Corrigé directement sur la branche 6.4.x et reporté sur master