View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000095SoothERPBugspublic2015-10-04 10:542017-01-26 18:34
Reportertoz 
Assigned To 
PriorityhighSeverityblockReproducibilityalways
StatusnewResolutionopen 
PlatformHébergement EVX OnlineOSOS Version
Product VersionRC1.1 
Target VersionFixed in Version 
Summary0000095: Problème de chargement des pages avec Firefox 41
DescriptionBonjour,

J'utilise depuis fin 2013 la RC1.1 sur un serveur avec PHP 5.4. Mis à part l'obligation d'éviter les caractères accentués dans les articles tout fonctionnait correctement.

Depuis la mise à jour de Firefox en version 41 j'obtiens des erreurs lorsque je clique sur des fiches clients ou articles. L'URL prend successivement des valeurs du type http://xxxxx.com/se/core/profil_collab/index.php#catalogue_articles_view.php%252525253Fref_article%252525253DA-000000-00114 [^]
Je vois le nombre derrière les % grossir dans la barre d'adresse jusqu'à ce que je tombe sur une erreur 404

En tâtonnant j'ai trouvé qu'en remplaçant le "escape" par un "encodeURI" dans "\profil_collab\themes\collab_fr\javascript\_general.js" j'accédais à nouveau à mes fiches client.
Malheureusement, lorsque je cliquais sur un article le même type d'erreur dans l'adresse apparaissait.

Dans le même temps sur un Firefox 40 tout marche impeccablement.

J'ai donc décidé d'upgrader sur la version dev, j'ai remis tous mes paramètres en place dans le dossier config et j'ai retrouvé ma liste de clients. Malheureusement le même type d'anomalie est survenu avec les factures et les articles.
Le "escape" était déjà remplacé dans le fichier "_general.js" par un "encodeURIComponent", j'ai tout de même tenté de le remplacer par un "encodeURI" et ça a fonctionné.

Malgré cela le problème est toujours présent quand je clique sur un article dans une recherche d'articles. De plus quand je tente d'ajouter un article sur un document il ne se passe rien, que ce soit en appuyant sur Entrée ou en cliquant sur Insérer.

Mes compétences en Javascript et PHP étant limitées, et ne connaissant pas bien le code de Sooth ERP, je me suis dit que vous sauriez peut-être m'aider à surmonter cette épreuve :)

Je suis à votre disposition si je dois effectuer une manip pour vous donner plus d'infos.
Additional InformationJ'ai déjà posté cette information sur http://community.sootherp.fr/ [^] mais je ne suis pas certain que cela ait fonctionné car je ne vois pas le message.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0000166)
Yves (administrator)
2015-10-04 15:53

Bonjour,

le post a fonctionné mais c'est parce que la catégorie "Développeurs" du "forum" dans laquelle est placée la question n'est accessible qu'une fois logué.
Il faut vous connecter avec vos identifiants (communs au forum / Wiki / bug tracker) et les messages de la catégorie en question seront accessibles.

J'ai fait cette même réponse également par mail mail je reçois en retour un permanent delivery failure (au passage: j'ai déjà rencontré ce souci dans d'autres circonstances avec votre fournisseur d'adresse email, donc je ne sais pas si c'est du au fournisseur ou à une saisie d'adresse mail erronée)

Yves
(0000167)
toz (reporter)
2015-10-04 19:21

Merci pour votre réponse,

Même connecté avec mes identifiants je ne peux pas accéder à la question sur community.

J'ai tenté de reproduire l'anomalie en utilisant Sootherp develop (https://github.com/yvesb/soothERP [^]) en local sous Windows avec Uniformserver Zero XI en PHP 5.4.45 et Firefox 41.0.1

En partant d'une base vide je n'ai pas constaté l'anomalie liée aux URL tout de suite, mais elle est revenue rapidement. J'ai seulement créé un client, un article, une facture. Et après quelques clics dès que je clique sur la facture depuis la fiche client, les anomalies dans l'URL reviennent. Je retrouve également le problème d'ajout d'article sur un document du type facture.

J'ai créé un nouveau profil dans Firefox sans modules complémentaires au cas où, mais j'obtiens les mêmes résultats !

Si vous avez une idée elle est la bienvenue ...
User avatar (0000168)
Yves (administrator)
2015-10-04 23:21

Oui, effectivement pour y accéder aux posts "Développeurs" il faudrait vous donner les privilèges développeurs dans Mantis (si vous souhaitez activement participer, c'est envisageable dites moi).
Pour le moment j'ai basculé de la catégorie "développeurs" à "problèmes".

Suite à votre précédent message, j'ai refait quelques tests et j'ai réussi à reproduire mais je ne sais pas à ce stade d'où ça vient. Il va falloir chercher ce qui a changé dans FF 41 au niveau du js notamment pour tenter de comprendre.

Pour le moment il faut donc rester sur FF 40 pour pouvoir utiliser Sootherp en attendant un correctif.
User avatar (0000169)
crepeausucre (developer)
2015-10-06 17:22

Bonjour,

La modification du escape par le escapeURI me parait être la bonne réponse à apporter. Attention toutefois il y a nombre de références à rechercher et remplacer, voici une liste (que j'espère exhaustive) :
find . -type f | xargs sed -i 's/escape(\"document/encodeURI(\"document/g'
 find . -type f | xargs sed -i 's/escape(\"utilisateur/encodeURI(\"utilisateur/g'
find . -type f | xargs sed -i 's/escape(\"annuaire/encodeURI(\"annuaire/g'
find . -type f | xargs sed -i 's/escape(\"catalogue/encodeURI(\"catalogue/g'
 find . -type f | xargs sed -i "s/escape('catalogue/encodeURI('catalogue/g"
 find . -type f | xargs sed -i "s/escape('annuaire/encodeURI('annuaire/g"
 find . -type f | xargs sed -i "s/escape('document/encodeURI('document/g"
 find . -type f | xargs sed -i "s/escape('utilisateur/encodeURI('utilisateur/g"
(0000170)
toz (reporter)
2015-10-06 19:23

Bonjour,

Juste pour rappel, au cas où cela pourrait vous être utile, dans la version dev le "escape" était déjà remplacé dans le fichier "/themes/default/js/_general.js" par un "encodeURIComponent". J'ai du remplacer ce "encodeURIComponent" par un "encodeURI" pour que les clics sur les factures depuis une fiche client fonctionnent.
User avatar (0000171)
Yves (administrator)
2015-10-06 21:01
edited on: 2015-10-06 21:03

Bonsoir,

A la base, j'avais déjà remplacé tous les "escape" dans des fichiers js (pas seulement general.js cf https://github.com/yvesb/soothERP/commit/f42bc4a26f370e689a2f85d5d4c6ba706df59866 [^])

J'avais plutôt opté pour encodeURIComponents. Pour être sincère je ne sais plus si c'est parce que j'avais rencontré des bugs avec encodeURI ou simplement parce que certains contenus encodés contiennent des paramètres dans l'URL ce qui me paraissait donc pertinent (cf SO http://stackoverflow.com/questions/75980/best-practice-escape-or-encodeuri-encodeuricomponent/3608791#3608791 [^])

Or si on compare les fonctions (source http://xkr.us/articles/javascript/encode-compare/ [^]):

Escape n'encode pas @*/+
EncodeURI n'encode pas [email protected]#$&*()=:/,;?+' (donc pour les paramètres c'est gênant à priori, non ?)
EncodeURIComponent n'encode pas ~!*()' (plus proche tout de même de escape me semble-il quand on pense à des paramètres notamment ?)

Par contre ce bug m'a fait chercher un peu plus et il y a, en dehors des js "core" d'autres escape dans le code (prototype.js) ou dans des pages html.

De plus il y a aussi du unescape, or il faudrait à priori remplacer ces unescape par soit decodeURI, soit decodeURIComponent (selon la fonction utilisée).
Pour corser un peu prototype.js fait ça dans une ligne ^ ^
json = decodeURIComponent(escape(json));

Enfin est ce qu'il n'y a pas côté Php une interaction également (et donc une fonction inapproprié après remplacement de escape)?

Toutes ces réflexion étant posées, je vais faire des tests en remplaçant par encodeURI puisque ça à l'air de marcher, mais je me demande au final si on peut faire les choses de façon systématique et s'il n'y a pas à faire du cas par cas selon le contenu (auquel cas ce n'est pas une mince affaire).

User avatar (0000172)
Yves (administrator)
2015-10-06 21:22

Et la présence de %D et %3F visibles dans l'url ne signifie-t-elle pas qu'il y a un double encodage ( de = et ?)?
Auquel cas, oui encodeURI résout ce double encodage car il ne les encode pas contrairement à encodeURIComponent
Mais du coup la question est pourquoi ? Car escape était censé encoder de la même manière que encodeURIComponent les caractères = et ?
A ce stade quelque chose m'échappe et j'ai l'impression que ce n'est pas qu'un problème directement sur les fonctions mais dans possiblement dans l'environnement...
User avatar (0000173)
crepeausucre (developer)
2015-10-06 21:33

C'est sûr que sans documentation et avec le code redondant ce n'est pas évident :-/

La clef est peut être dans le fait que la navigation se fait via l'ancre et tout en javascript : l'encodage dans l'URL ne fait du sens que lorsque la requête est envoyée par le navigateur au serveur pour qu'il n’interprète pas les = et ? d'un paramètre qui s'appelerai "URL". Ici c'est Javascript qui lit l'ancre pour rediriger.

Je vous tiendrai informé des tests avec encoreURI sur plusieurs installations.
User avatar (0000174)
Yves (administrator)
2015-10-08 00:22

Je pense qu'il y a vraiment un problème de sur / double encodage.
Je ne sais pas quel est le lien avec FF41, mais il révèle le souci qui était sous-jacent à mon sens.

Si je regarde les logs Apache on trouve par ex. du %2523 dans les URL fautives au niveau du paramètre.

Maintenant si je prends le cas de la page d'accueil / bureau
Si je remplace dans page_accueil.inc.php ligne 133

page.verify('index', 'index.php#' + escape('documents_edition.php?ref_doc=<?php echo $open_doc->ref_doc; ?>'), 'true', '_blank');

Par (donc retrait total de l'encodage)

page.verify('index', 'index.php#documents_edition.php?ref_doc=<?php echo $open_doc->ref_doc; ?>', 'true', '_blank');

...ça marche.

Ça a le même effet que remplacer escape par encodeURI car encodeURI n'encode pas les ? ni le = (or escape le fait commme encodeURIComponent).

Par contre là, en l’occurrence, il y a encore de l'encodage une nouvelle fois derrière la ligne modifiée (ou une absence de décodage à un moment donné) vu ce que reçoit Apache. Donc tant qu'à modifier, j'enlèverai plutôt totalement les encodages superflus (comme ça semble être le cas ici), plutôt que de mettre du encodeURI qui en surface va résoudre le pb mais qui risque de surencoder certains caractères selon la situation.

En poussant donc la recherche, je remarque que la méthode verify dans general.js fait à un moment

//ouverture de page depuis un hash
        if (div_target == "sub_content") {
            lehash = document.location.hash.substr(1, document.location.hash.length);
            if (lehash != "") {
                if (historique.length == 0) {
                    targeturl = encodeURI(lehash);
                    historique.unshift(targeturl);
                    historique_request.unshift(new Array());
                    document.location.hash = decodeURI(targeturl);
                }
            }
        }

Je n'ai pas regardé de plus près à ce stade, mais on a donc déjà semble-t-il un encodage et décodage à ce niveau, donc à priori on pourrait se passer de tous les encodages des pages.verify je pense.

Par contre étant donné qu'il y a des paramètres dans les url, il vaudrait mieux encodeURIcomponent / decodeURIComponent dans verify, non? (ce qui existe actuellement dans la méthode en questionest inchangé depuis LMB)

Je ne comprends toujours pas pourquoi le pb apparaît (seulement) avec FF41...

Un avis ?
User avatar (0000175)
Yves (administrator)
2015-10-08 08:08

Merci Erwan (j'ai vu ta réponse par mail).

Je vais tâcher de faire des essais en éliminant les encodages qui semblent redondants.

Je vous ferai un retour sur le résultat.
(0000177)
networkinfo (reporter)
2016-03-09 15:16
edited on: 2016-03-09 15:17

Bonjour

J'ai corrigé le pb des 404 sur la page d'accueil en supprimant le escape ligne 140 du fichier profil_collab/themes/collab_fr/page_accueil.inc.php

Ca devient
         <script type="text/javascript">
                                                    Event.observe('open_doc_<?php echo $open_doc->ref_doc; ?>', "click", function(evt){
                                                        page.verify('index','index.php#'+'documents_edition.php?ref_doc=<?php echo $open_doc->ref_doc; ?>','true','_blank');
                                                        Event.stop(evt);
                                                    });

                                                </script>

(0000178)
hibox (reporter)
2016-09-02 12:48

Bonjour à tous, bonjour Yves

Je rencontre les mêmes difficultés. Est-ce qu'il y a du nouveau ? Lorsque j'accède aux informations de livraison depuis la liste des commandes. Je suis redirigé vers la page

https://monsite.ext/profil_collab/index.php#documents_edition_generer_blank.php%3Ffonction_generer%3Dgenerer_bl_client%26ref_doc%3DCDC-000000-00737 [^]

Dans l'url je remplace à la main les caractères suivants :
%3F par ?
%3D par =
%26 par &

J'obtiens une page qui s'affiche correctement : https://monsite.ext/profil_collab/index.php#documents_edition_generer_blank.php?fonction_generer=generer_bl_client&ref_doc=DCDC-000000-00737 [^]

Mes questions :
Quelle est la version du code du repo git qui dispose de ce correctif ?
Une release est-elle prévue ?


Merci pour votre retour.
Louis

PS: j'ai un autre problème à l'affichage de cette page. Peut être est-ce lié ? SoothERP me demande de m'authentifier à nouveau. Est-ce que ça peut être en lien avec le bug d'encodage ou est-ce autre chose ?
(0000180)
hibox (reporter)
2016-09-02 15:40

J'ai poursuivi mes recherches. Ok ce serait la branche utf8 qui corrige le pb. Testé pour FF >= 41.0 ?

Il y a plusieurs point encore obscurs pour moi donc je pose les questions assez naïvement

Est-ce que le merge de la branche utf8 avec master a été testée ?
Est-ce que le merge de la branche develop avec master a été testée ?

Et surtout est-ce que c'est ce qu'il faut faire histoire de ne pas passer trop de temps à tester des choses inutiles ?
Il y a bcp plus de fichiers dans https://github.com/yvesb/soothERP/tree/master/src/2.071.0 [^]
que dans https://github.com/yvesb/soothERP/tree/develop/src/2.071.0 [^] du coup je voudrais être bien sûr des implications.

Merci de votre aide

Ma version / config :
php 5.6
mysql 5.7
RC1.1
datas issues de LMB Community
Firefox 48 sous mac (et 40.0.3 pour LMB actuel)

Merci de votre aide

- Issue History
Date Modified Username Field Change
2015-10-04 10:54 toz New Issue
2015-10-04 15:53 Yves Note Added: 0000166
2015-10-04 19:21 toz Note Added: 0000167
2015-10-04 23:21 Yves Note Added: 0000168
2015-10-05 23:25 Yves Note View State: 0000168: public
2015-10-06 17:22 crepeausucre Note Added: 0000169
2015-10-06 19:23 toz Note Added: 0000170
2015-10-06 21:01 Yves Note Added: 0000171
2015-10-06 21:03 Yves Note Edited: 0000171 View Revisions
2015-10-06 21:22 Yves Note Added: 0000172
2015-10-06 21:33 crepeausucre Note Added: 0000173
2015-10-08 00:22 Yves Note Added: 0000174
2015-10-08 08:08 Yves Note Added: 0000175
2016-03-09 15:16 networkinfo Note Added: 0000177
2016-03-09 15:16 networkinfo Note Edited: 0000177 View Revisions
2016-03-09 15:17 networkinfo Note Edited: 0000177 View Revisions
2016-09-02 12:48 hibox Note Added: 0000178
2016-09-02 13:30 hibox Note Added: 0000179
2016-09-02 13:31 hibox Note Deleted: 0000179
2016-09-02 15:40 hibox Note Added: 0000180


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker