FusionForge de l'ADULLACT: openMairie - Framework : [#9499] Pas de raffraichissement du formulaire en sousform via action directe dans un environnement 2 frontaux Apache : un en https

Date :
30/03/2021 21:00

Priorité :
1

État :
Closed

Proposé par :
Florent MICHON (fmichon)

Confié à :
Florent MICHON (fmichon)

Sévérité :
none

Version cible :
4.9.10

Version concernée :
4.9.9

Résumé :
Pas de raffraichissement du formulaire en sousform via action directe dans un environnement 2 frontaux Apache : un en https > un en http

Description détaillée
Ce bug se produit uniquement dans le cas d'un environnement 2 frontaux Apache : le premier gère le SSL, le second sert l'application openMairie. Entre le premier et le second, les données ne sont plus en HTTPS, le frontal de l'application openMairie n'a pas connaissance du SSL en place avant lui. Au chargement d'un sous formulaire via une requête régulière, une URL callback pour le rafraîchissement via XMLRPC est générée et placée dans le DOM. Pour composer cette URL, openMairie interroge une variable globale ($_SERVER["HTTPS"]). Celle-ci est à false : l'URL est construite avec un scheme HTTP En fonction des actions de l'utilisateur, cette URL peut-être utilisée. C'est le cas pour les actions directes. Dans ces cas-là, cette URL est appelée en XMLRPC pour rafraîchir le contenu du sous-formulaire pour présenter des données à jour. L'URL étant en HTTP alors qu'on est en HTTPS dans la barre d'adresse, le navigateur bloque l'appel : l'action utilisateur a bien été traitée, mais l'affichage n'est pas à jour. Un rafraîchissement manuel de la page présente les données à jour. La bonne pratique reste configurer un certificat SSL sur le Apache qui sert l'application openMairie, les données sont ainsi chiffrées de bout en bout. Ce correctif intervient pour gérer les cas où ceci n'est pas envisageable.
Ce bug se produit uniquement dans le cas d'un environnement 2 frontaux Apache : le premier gère le SSL, le second sert l'application openMairie. Entre le premier et le second, les données ne sont plus en HTTPS, le frontal de l'application openMairie n'a pas connaissance du SSL en place avant lui. Au chargement d'un sous formulaire via une requête régulière, une URL callback pour le rafraîchissement via XMLRPC est générée et placée dans le DOM. Pour composer cette URL, openMairie interroge une variable globale ($_SERVER["HTTPS"]). Celle-ci est à false : l'URL est construite avec un scheme HTTP En fonction des actions de l'utilisateur, cette URL peut-être utilisée. C'est le cas pour les actions directes. Dans ces cas-là, cette URL est appelée en XMLRPC pour rafraîchir le contenu du sous-formulaire pour présenter des données à jour. L'URL étant en HTTP alors qu'on est en HTTPS dans la barre d'adresse, le navigateur bloque l'appel : l'action utilisateur a bien été traitée, mais l'affichage n'est pas à jour. Un rafraîchissement manuel de la page présente les données à jour. La bonne pratique reste configurer un certificat SSL sur le Apache qui sert l'application openMairie, les données sont ainsi chiffrées de bout en bout. Ce correctif intervient pour gérer les cas où ceci n'est pas envisageable.

Commentaires (1)
Pièces jointes
Modifications (2)

Message
Date : 30/03/2021 21:48 Expéditeur : Florent MICHON * Correction OK https://adullact.net/scm/viewvc.php/openmairie?view=revision&revision=4677 * Tests OK

Pas de documents joints

Champ	Ancienne valeur	Date	Par
status_id	Open	30/03/2021 21:48	Florent MICHON
close_date	Aucun(e)	30/03/2021 21:48	Florent MICHON

Powered By FusionForge Collaborative Development Environment

Charte d'utilisation / Nous contacter / Mentions légales

Haut de page