Projet

Général

Profil

Anomalie #4097

bug HTTPS dans la fonction url_de_base() sur certains serveurs mal configurés

Ajouté par Pierre-Aurélien Georges il y a environ un an. Mis à jour il y a 10 mois.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
Début:
14/02/2018
Echéance:
% réalisé:

0%

Resolution:
wontfix
Navigateur:

Description

Bonjour,

voici le contexte : le serveur web de mon hébergeur est mal configuré (et je n'ai malheureusement pas réussi à leur faire corriger le problème). Le site web [[https://bcl.cnrs.fr]] est accessible aussi bien en HTTP qu'en HTTPS, mais en allant sur /ecrire/?exec=info je vois que le serveur ne renseigne ni la variable $_SERVER['HTTPS'] ni la variable $_SERVER["SCRIPT_URI"], et à vrai dire lorsque je compare sur ce serveur un phpinfo() en HTTP et un phpinfo() en HTTPS je vois qu'il y n'a strictement AUCUNE différence entre les deux, et qu'il est donc totalement impossible de savoir (côté serveur) si la requête a été faite en HTTP ou en HTTPS.

Dans ce contexte bien précis, le code de la fonction url_de_base() situé dans /ecrire/inc/utils.php pose problème, car il se base sur le contenu de ces deux variables $_SERVER['HTTPS'] et $_SERVER["SCRIPT_URI"] pour choisir entre HTTP et HTTPS et il ne tient absolument pas compte du contenu du champ META, ce qui dans mon cas est bien dommage car j'y ai mis l'url en https:...

La conséquence de tout ceci est qu'en HTTPS cela entraîne des problèmes d'affichage d'images et de CSS qui ne sont pas bien appliqués, cf. [[https://contrib.spip.net/Passer-un-site-SPIP-sous-https#forum491839]]. Sur ce forum, vous verrez que je ne suis pas le seul à avoir affaire à un serveur mal configuré de la sorte, et que nous sommes plusieurs à avoir ce même problème. La solution de bricolage donnée par un des participants du forum est de rajouter dans /config/mes_options.php les deux lignes suivantes :

$_SERVER['HTTPS'] = "on";
$_SERVER['SERVER_PORT']='443';

Ca fonctionne, certes, et c'est donc ce que j'ai fait pour mon site, mais c'est vraiment du bricolage et c'était pas évident de trouver cette astuce !

Pour faire plus propre et plus simple, serait-il possible à l'avenir de modifier le code de url_de_base() pour qu'en l'absence de ces deux variables $_SERVER['HTTPS'] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c'est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ? En effet, lorsque META commence par "https://" ça veut dire que le serveur gère le HTTPS, et donc s'il ne renseigne pas les variables HTTPS et SCRIPT_URI et bien dans le doute mieux vaut générer des url de base en "https://" plutôt qu'en "http://" car si cette url de base se retrouve mentionnée au sein d'un fichier html ou css, et que le fichier en question est demandé en HTTP, ce n'est pas grave s'il contient des ressources en HTTPS, alors que le contraire pose problème (ne pas mettre de ressources en HTTP au sein d'une page en HTTPS !)

Révisions associées

Révision 23964 (diff)
Ajouté par brunobergot@gmail.com il y a 11 mois

Fix #4097 : améliorer url_de_base() pour mieux détecter si le site est en https

Si on ne trouve pas l'info dans `$_SERVER['HTTPS']` et `$_SERVER["SCRIPT_URI"]`, on teste le scheme de la meta adresse_site.

Historique

#1 Mis à jour par b b il y a environ un an

  • Version cible mis à 3.2

#2 Mis à jour par b b il y a environ un an

  • Statut changé de Nouveau à En cours

le serveur web de mon hébergeur est mal configuré

Ca fonctionne, certes, et c'est donc ce que j'ai fait pour mon site, mais c'est vraiment du bricolage

Tout est dit, serveur mal configuré, bricole pour contourner le bug de l'hébergeur en question :p Mais au moins, ça fonctionne.

Pour faire plus propre et plus simple, serait-il possible à l'avenir de modifier le code de url_de_base() pour qu'en l'absence de ces deux variables $_SERVER['HTTPS'] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c'est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ?

L'idée semble bonne à premier vue tellement ça parait simple, mais j'ai peur que cela ait des effets de bord sur certaines configurations, notamment derrière un proxy. Attendons les avis des autres membres de l'équipe avant de l'intégrer ou non.

#3 Mis à jour par Fil _ il y a environ un an

ça a l'air plutôt logique

#4 Mis à jour par b b il y a 11 mois

Appliqué sur le trunk, attendons les retours avant un éventuel report en 3.2.

#5 Mis à jour par b b il y a 11 mois

  • Assigné à mis à b b

#6 Mis à jour par cedric - il y a 11 mois

C'est casse gueule car url_de_base() utilise le nom de domaine de l'URL courante et pas celui de la meta adresse site, et rien ne garantit que le certificat soit aussi valide pour ce domaine.

Typiquement si le site est accessible en http par un nom de domaine générique on rend cet accès inopérant dans ce cas.
Je pense que si on veut aller par là, il faut vérifier que le nom de domaine est le même que celui de la meta adresse site, et je ne sais pas si malgré tout c'est une bonne idée car avec ce patch on perd la distinction http/https à partir du moment où on a mis https dans l'adresse du site.

J'aurais tendance à penser qu'en cas de serveur mal configuré, cas exotique, le hack dans le mes_options.php est la meilleure option

$_SERVER['HTTPS'] = "on";
$_SERVER['SERVER_PORT']='443';

car il est fait en connaissance de cause (le serveur est mal configuré, ne pas attendre un en-tête https) alors que le patch dans le core va influer le comportement de tout le monde, y compris sur les serveurs bien configurés

#7 Mis à jour par b b il y a 11 mois

Merci pour le retour, je partage aussi ton avis cf mon commentaire plus haut. J'annule r23964 et on ferme le ticket en invalid/wontfix ?

Dans ce cas, il faudrait au moins documenter l'astuce du mes_options dans cet article de contrib par exemple : https://contrib.spip.net/Passer-un-site-SPIP-sous-https

#8 Mis à jour par b b il y a 10 mois

  • Statut changé de En cours à Fermé
  • Resolution mis à wontfix

Je viens d'annuler r23964 avec r23967 et j'ai ajouté un avertissement dans le PS de l'article de contrib https://contrib.spip.net/Passer-un-site-SPIP-sous-https

On ferme.

Formats disponibles : Atom PDF