Passer un site SPIP sous https://

Discussions par date d’activité

20 discussions

• 4

  

  Manuel

  Décembre 2017

  Bug espace privé suite au passage à HTTPS

  Depuis le passage de notre site en HTTPS, avec redirection HTTP->HTTPS + HSTS au niveau serveur, l’espace privé est inutilisable à moins de désactiver Javascript.

  Je remarque dans le code source que de nombreuses adresses sont restées en HTTP, notamment celle issue de la ligne 11 de /prive/squelettes/inclure/head.html :

  function test_accepte_ajax(){jQuery.ajax({"url":"[(#URL_ECRIRE{test_ajax,js=1}|replace{'&','\x26'})]"});}

  qui devient dans le code source

  function test_accepte_ajax(){jQuery.ajax({"url":"http://monsite.com/ecrire/?exec=test_ajax\x26js=1"});}

  au lieu de

  function test_accepte_ajax(){jQuery.ajax({"url":"https://monsite.com/ecrire/?exec=test_ajax\x26js=1"});}

  De même que tous les appels de CSS qui commencent par HTTP au lieu de HTTPS.

  Du coup, tout ce qui a recours à AJAX ne fonctionne pas.

  On dirait que #URL_ECRIRE continue à utiliser l’URL http et non pas https.

  L’espace privé est utilisable sans le javascript, mais cela pose quelques problèmes quand il faut valider plusieurs posts de forums en même temps.

  Sinon aucun problème dans l’espace public, mais je n’utilise pas la balise #INSERT_HEAD

  Quelques infos :

  Version SPIP : 3.2
  Version PHP 5.4.45
  MySQL 10.0.32-MariaDB-0

  Bonne réception, cordialement.

  Manuel

  • 

    erational

    Décembre 2017

    As tu changé l’adresse du site dans le menu configuration avec le https// et vidé ton cache ?

  • 

    Manuel

    Décembre 2017

    Oui, l’adresse du site dans configuration comment par https:// et le cache a été vidé.

  • 

    pa.georges

    Février 2018

    Bonjour, essayez la solution donnée par toto21, à savoir de mettre les deux lignes suivantes dans le fichier /config/mes_options.php :

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

    Chez moi ça a réglé le problème.

  • 

    Manuel

    Février 2018

    En ajoutant ces deux lignes, cela fonctionne. Merci beaucoup.

  Répondre à ce message

• 1

  

  conil26

  Mars 2017

  A l’étape 4, selon les FAI, la redirection indiquée ne suffit pas :

  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

  Il vaut mieux l’écrire en dur :

  RewriteEngine on
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteRule (.*) https://www.monsite.com/$1 [R=301,L]

  en remplaçant :
  https://www.monsite.com/
  par l’adresse du site concerné.

  Il faut aussi penser à ajouter dans :

  ../config/mes_options.php
  	 $_SERVER['SERVER_PORT']='443';
  	 $_ENV["SERVER_PORT"]='443';

  • 

    pa.georges

    Février 2018

    Sur certains serveurs (c’est mon cas), la variable Apache %HTTPS renvoie toujours off, même en mode HTTPS, et la variable %HTTP:X-Forwarded-Proto renvoie toujours une chaîne vide. Il ne sert alors absolument à rien de mettre ces RewriteCond / RewriteRule dans le .htaccess...

    En revanche, le fait de mettre les deux lignes suivantes dans le fichier /config/mes_options.php suffit, en soi, à régler tous les problèmes :

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

    Merci à toto21 pour cette suggestion.

  Répondre à ce message

• 

  spbzh

  Février 2018

  Voici la pièce jointe

  

  Répondre à ce message

• 

  spbzh

  Février 2018

  Voici la pièce jointe.

  

  Répondre à ce message

• 

  spbzh

  Février 2018

  Bonjour,

  Suite au passage d’un SPIP 3.0.26 en https, lorsque je souhaite ajouter une image à un article, j’ai le message Forbidden (cf capture).
  Le site marche très bien en http.
  Les versions du serveur sont :
  -  Apache/2.2.22
  -  PHP 5.6.30
  -  Mysql 5.5.59

  J’ai suivi les recommandations de toto21 et conil26, mais sans succès.
  Il s’agit d’un site avec le plugin EVA-WEB 4.2
  Nous avons déjà réalisé le même passage vers https avec un autre site SPIP 3.0.26 mais avec le plugin Sarka-SPIP 3.2.36 sur un autre serveur.
  Les 2 serveurs ont la même configuration et nous ne rencontrons pas ce problème.

  Les droits sur les dossiers et fichiers sont les mêmes sur les 2 sites.

  Merci de votre aide.

  Répondre à ce message

• 3

  

  pa.georges

  Avril 2017

  Bonjour,
  j’ai des squelettes *.css.html avec des règles css contenant

  background: url(...) 

  qui utilisent la balise #CHEMIN, et cette balise génère bien effectivement des chemins relatifs, mais ensuite dans le fichier css minifié généré lors de la mise en cache par SPIP, les url(...) sont converties en url absolues qui commencent par http:// au lieu de https://... C’est très gênant que le minifier CSS de SPIP remplace automatiquement toutes les URLs relatives par des URLs absolues, sans raison apparente. Comment désactiver cela et faire en sorte de conserver des urls relatives dans le fichier CSS minifié ?

  (Pour la petite histoire, c’est le filtre |compacte qui appelle le filtre |url_absolue_css qui se charge de réécrire toutes les url(...) relatives en url(...) absolues, et je ne comprends pas en quoi ceci s’appelle un « compactage »... Pour moi c’est plutôt un décompactage, puisque l’url absolue prend plus de place que l’url relative !!!)

  • 

    pa.georges

    Septembre 2017

    Bon, alors je me réponds à moi-même :
    la fonction url_absolue(), définie dans le fichier ecrire/inc/filtres_mini.php, fait appel en interne à la fonction url_de_base(), définie dans le fichier ecrire/inc/utils.php, et cette dernière ne se base absolument pas sur le contenu de meta[adresse_site], comme on aurait pu s’y attendre (c’est expliqué et justifié dans les commentaires de la fonction). Au lieu de cela, elle teste si la variable $_SERVER[« SCRIPT_URI »] commence par « https » ou si la variable $_SERVER[’HTTPS’] est présente et vaut autre chose que « Off ».

    Or il se trouve que dans mon cas de figure, le serveur Apache de notre hébergeur web ne positionne aucune de ces deux variables, et donc la fonction url_de_base() échoue à bien détecter si l’internaute a demandé du HTTPS ou pas.

    Solutions au problème : demander à l’hébergeur de bien vouloir rajouter l’une de ces deux variables sur la config de son serveur Apache, ou bien sinon, si on ne le peut pas, surcharger la fonction url_absolue() en créant une fonction filtre_url_absolue() dans le fichier squelettes/mes_fonctions.php, qui se contente d’appeler url_absolue() en lui renseignant « https://... » dans le deuxième paramètre de la fonction.

    Ceci dit, apparemment je suis un des rares à avoir eu ce problème, ce qui me laisse penser que la plupart du temps, un serveur web standard publie au moins l’une ou l’autre de ces deux variables $_SERVER[« SCRIPT_URI »] ou $_SERVER[’HTTPS’] , donc peut-être qu’il serait judicieux de patcher la fonction url_absolue() pour que, en l’absence de $_SERVER[« SCRIPT_URI »] et de $_SERVER[’HTTPS’], elle se base sur la présence de « https » ou pas en début de meta[adresse_site], au lieu d’en déduire un peu hâtivement que par défaut c’est du « http »...

  • 

    Z

    Septembre 2017

    Bonjour pa.georges

    J’ai exactement le même problème que toi, et ton post m’a beaucoup aidé. J’ai fait une petite page de test rapide de ces 2 variables, et effectivement, ni l’une ni l’autre ne sont positionnées.
    https://www.c-nous.loc/apache.php
    Ce n’est peut-être pas si rare de voir cela.... Je vais donc suivre tes conseils et voir s’il est possible d’obtenir le positionnement de l’une des 2 variables, ou à défaut, écrire la surcharge que tu préconises ne devrait pas être trop compliqué.

    ++
    Z

  • 

    toto21

    Décembre 2017

    Bonjour,
    [Version de SPIP : 3.0.X]
    En effet certains serveurs ne fournissent entre une connexion http / https qu’une seule variable serveur pour indiquer le protocole https :

    $_SERVER['HTTP_X_FORWARDED_PROTO'] = 'https'

    Configuration faible du serveur ? Celui sur lequel je dois travailler maintient même la valeur $_SERVER[’SERVER_PORT’] sur 80 même lors de l’appel d’une page en https!

    Du coup pour résoudre le problème j’ai du artificiellement positionner la variable $_SERVER[’SCRIPT_URI’] à la valeur ’https://’ (il semble que $_SERVER[’HTTPS’] sur on, soit équivalent et plus élégant ;) - j’ai par sécurité mis les deux) - cependant cela ne suffit pas, les appels ajax ne s’y retrouvent pas (par exemple sur la page pour vider le cache), sans placer $_SERVER[’SERVER_PORT’] sur le port https 443.
    Donc voici ce que j’ai du ajouter dans le fichier ../config/mes_options.php :

    $_SERVER['SCRIPT_URI'] = 'https://';
    $_SERVER['HTTPS'] = "on";
    $_SERVER['SERVER_PORT']='443';

    Dans ce contexte voir la solution de conil26 ci-dessous pour forcer la redirection https.
    Encore merci à pa.georges pour m’avoir mis sur la bonne piste.

  Répondre à ce message

• 

  Pascal Engelmajer

  Juin 2017

  Bonjour,
  Le site marche tout à fait bien en http. Je n’ai pas redirigé le http vers https.
  lorsque j’essaie
  https://www.monsite.com/test.html
  -  avec .htaccess (# Fichier .htaccess SPIP v 3.1)
  j’obtiens une erreur 403 Forbidden (Forbidden /You don’t have permission to access / on this server.)
  sans .htaccess (renommé htaccess.txt)
  j’obtiens bien le contenu du fichier test.html avec la notion sécurisé dans la barre d’adresse)
  je ne sais pas quoi faire...
  Merci de votre aide

  Répondre à ce message

• 1

  

  Manu

  Mars 2017

  Je me pose des questions sur le contenu des articles : si le texte de ces derniers contient des liens en http du style[Voir l'article->http://mondomaine.tld], est-ce un souci ? (parce que ce serait complètement inenvisageable de modifier tous ces liens...)

  • 

    erational

    Mars 2017

    Non ce n’est pas un problème :

    • si c’est un lien externe, c’est autorisé
    • si c’est un lien interne ( même si c’est plus propre d’utiliser un raccourci du type [voir l'article->56] ). Cela fonctionnera car dans le .htaccess on a la redirection vers le https.

  Répondre à ce message

• 1

  

  Nicolas Friedli

  Février 2017

  Selon la configuration du serveur — lorsqu’il tente de repasser systématiquement sur le port 80 —, on pourra aussi penser à ajouter un ceci dans mes_options.php :

  $_SERVER['SERVER_PORT']='443';

  • 

    Peetdu

    Mars 2017

    Merci erational pour cet article et merci Nicolas pour cette précision. Les deux m’ont été bien utiles

  Répondre à ce message

• 1

  

  thx11

  Février 2017

  Info très utile.
  Est ce que ces réglages permettent de se passer complétement du plugin redirhttps?

  • 

    erational

    Février 2017

    Oui à priori, si vous passez tout le site en https://, le plugin redirhttps ne sert plus à rien.

  Répondre à ce message