Editeur wysiwyg invisible

Daniel JOUVENOT · le 09/10/13 à 09:15

Bonjour,

Lorsqu'un contributeur édite un contenu (de type article) sur notre serveur de production, l'éditeur wysiwyg est invisible, à moins de débloquer la protection mise en place par le navigateur et d'accepter d'afficher le contenu non sécurisé.

L'appel à l'éditeur wysiwyg doit certainement se faire en http alors que nous sommes en https.

Serait il possible dans une prochaine version de JCMS de corriger cela ?

Merci.

5 pts
Olivier Jaquemet · le 09/10/13 à 09:38

Bonjour,

Vous avez omis de préciser votre version de JCMS, et le navigateur utilisé (si le symptome est spécifique à un navigateur)

Nous utilisons quotidiennement l'éditeur wysiwyg sur notre intranet, en https, et nous n'avons aucune erreur de ce type. Peut être avez vous un développement spécifique sur l'éditeur ? Vérifiez également que la fusion et la compression des CSS et des JS est activé dans les propriétés du site.

0 pt
Daniel JOUVENOT · le 09/10/13 à 17:15

Excusez moi j'ai effectivement oublié de vous donner certaines précisions.

Notre version de JCMS utilisée en production est JCMS 7.1.2. Le symptôme existe sur l'ensemble des navigateurs. Ce symptome disparait en cliquant sur le bouclier à droite de l'URL pour chrome (le message est alors "cette page contient un script provenant de sources non authentifiés"), à gauche de l'URL sur le bouclier sous firefox (message : "Firefox a bloqué du contenu non sécurisé"), etc pour internet explorer.

Curieusement, en me renseignant ce matin ce problème qui m'avait été remonté par certains contributeurs n'apparait pas pour tous les contributeurs. Je ne connais pas exactement les réglages de leurs navigateurs, néanmoins je constate ce problème sur le mien, je n'ai pas de réglage particulier et le message envoyé par les différents navigateurs semblent détecter du contenu non sécurisé qu'ils finissent par bloquer.

J'avais effectivement déjà joué sur les paramètres de fusion des JS et CSS sans succès. Pour la compression je n'ai que la propriété "Compresser le contenu HTML" mais cette propriété ne modifie pas non plus le comportement décrit à l'édition d'un contenu.

A la place de l'éditeur wysiwyg j'ai 2 liens bleus Paragraphe et classicStylesPoliceTaille police ... Le problème n'est pas insurmontable car il suffit donc de dire au navigateur d'accepter d'afficher du contenu non sécurisé mais je comprend que cela puisse être troublant pour certains contributeurs qui ont ce problème.

#1

Comme vous l'avez tout à fait compris, ce message se produit si la page mélange des requetes HTTP alors qu'elles est accédé en HTTPS.
JCMS ne mélange pas l'utilisation des protocoles, c'est tout l'un ou tout l'autre (normalement bien sur).

Pour diagnostiquer le problème, lancer les outils des dev de votre navigateur et récupérez les URLs qui sont accédées en HTTP. A partir de là nous pourrons tenter de comprendre l'origine du problème et savoir pourquoi le comportement nominal n'a pas lieu chez vous.

Olivier Jaquemet · le 09/10/13 à 18:25
#2

J'ai déjà vu ça chez des clients où JCMS est configuré en http et où le frontal fait de la réécriture d'URL à la volée dans les pages pour faire du https... mais il oublie certains liens qui restent en http du coup (notamment dans les css et les js)...

Ronan Kerdudou · le 12/10/13 à 00:23
#3

Nous utilisons un boitier accélérateur SSL en amont du frontal apache qui lui même est en amont du tomcat. Ce qui doit faire croire à Tomcat que nous sommes en HTTP.

Les requêtes demandés en HTTP sont :

  • /js/tiny_mce/themes/advanced/skins/default/ui.css
  • /js/tiny_mce/plugins/jcms/css/ui.css
  • /js/tiny_mce/plugins/inlinepopups/skins/clearlooks2/window.css
  • /js/tiny_mce/themes/advanced/skins/default/content.css
  • /js/tiny_mce/plugins/spellchecker/css/content.css
  • /css/jalios/core/core.css
  • /css/wysiwyg.css
  • /js/tiny_mce/themes/advanced/skins/default/content.css
  • /tiny_mce/plugins/spellchecker/css/content.css
  • /css/jalios/core/core.css
  • /css/wysiwyg.css
Benoit Ferlet · le 05/11/13 à 18:28
0 pt
Daniel JOUVENOT · le 21/10/13 à 11:59

Après plusieurs tests je me suis rendu compte qu'il y a effectivement une réécriture http/https en frontal qui n'est pas pris en compte par le js et donc l'éditeur wysiwyg. C'était donc lié à un problème système interne à mon entreprise. Effectivement en modifiant les connecteurs tomcat le problème semble résolu.

Merci pour votre aide. 

1 pt