Rediriger en HTTPS quand l’utilisateur est connecté

Passez automatiquement en HTTPS pour les pages contenant des informations privées (espace privé, login, crayons...)

Intérêt d’utiliser HTTPS

Pour éviter que les informations de connexion circulent en clair sur le réseau, ou pour empêcher l’usurpation d’identité, il est de bon ton de protéger certaines pages de SPIP, généralement :

  • l’espace privé
  • la page de login

Mais il est aussi important de protéger les pages publiques qui permettent d’une manière ou de l’autre de modifier la base de données, par exemple avec les crayons.

Fonctionnement du plugin

Le plugin est très simple et change simplement le protocole de HTTP à HTTPS si :

  • le visiteur est connecté (i.e. quand il existe un cookie de session)

ou si

  • la page demandée est la page de login

A noter : l’espace privé est bien protégé puisqu’on ne peut y accéder qu’en s’étant authentifié, ce qui crée le cookie de session.

Configuration du serveur web

Pour utiliser le plugin, il faut évidemment que le serveur web (Apache, par exemple) soit configuré pour servir en HTTP et en HTTPS.

Contenu mixte HTTP et HTTPS

Normalement, SPIP générera toute la page en HTTP, ou en HTTPS, mais pas de contenu mixte. En revanche, les librairies Javascript, par exemple OpenLayers, ou tout autre code ajouté à la main devra gérer HTTP et HTTPS pour éviter ce contenu mixte. Pour cela, il est possible d’ajouter un proxy PHP par exemple.

Attention : Pour les versions de SPIP antérieures à 2.1.11, vous devez modifier le core. Pour que tout fonctionne bien, les pages servies en HTTP et en HTTPS doivent piocher dans un cache différent, sinon tout se mélange. Si votre installation de SPIP ne contient pas encore la modification http://core.spip.org/projects/spip/repository/revisions/17941, il faut l’ajouter à la main :

  • ouvrir le fichier ecrire/public/assembler.php
  • dans la fonction calculer_contexte_implicite(), ajouter la ligne avec HTTPS pour obtenir :
            $contexte_implicite = array(
                    'squelettes' => $GLOBALS['dossier_squelettes'],
                    'host' => $_SERVER['HTTP_HOST'],
                    'https' => $_SERVER['HTTPS'],
                    'espace' => test_espace_prive(),
                    'marqueur' => (isset($GLOBALS['marqueur']) ?  $GLOBALS['marqueur'] : ''),
                    'notes' => $notes?$notes('','contexter_cache'):'',
            );

Cette modification est incluse dans le core de spip à partir de 2.1.11, et également dans spip3. La manipulation n’est donc pas nécessaire pour ces dernières versions.

Discussion

12 discussions

  • 1

    Merci pour ce plugin !

    Nous avons néanmoins eu besoin d’adapter le plugin pour qu’il fonctionne dans le cas d’une installation faite dans un sous-dossier (/site par exemple). Vous trouverez la documentation ici, si vous voulez l’intégrer ! Elle contient également des informations pour que cela fonctionne derrière un reverse proxy.

    • Merci.
      À défaut de l’intégrer au code, je l’intègre à la mémoire locale (= je recopie ici) :

      Le plugin redirhttps permet de forcer l’accès en HTTPS à la page de connexion ainsi qu’aux autres pages une fois connecté.

      Il peut néanmoins être intéressant de le modifier pour prendre en compte une installation dans un sous-dossier, non géré pour l’instant (v0.1.1). Une fois le plugin installé, modifiez le fichier plugin/redirhttps/redirhttps_options.php pour que la condition ressemble à ceci :

      if ((_request('page') == 'login' || isset($_COOKIE['spip_session']))
          && (empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] !== 'on')
          && $_SERVER['REQUEST_METHOD'] == 'GET') {

      Enfin, derrière un reverse proxy, il faudra modifier certaines variables utilisées par SPIP pour générer les URLs et par ce plugin pour déterminer si on accède à la page en HTTPS. Pour ce faire, vous pouvez créer un fichier conf/mes_options.php contenant les lignes suivantes :

      <?php
      /**
       * Récupération et définition des en-têtes données par le reverse proxy.
       */
      if (!empty($_SERVER['HTTP_X_FORWARDED_HOST']))
        
      $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
      if (!empty(
      $_SERVER['HTTP_X_REAL_IP'])
          && (
      filter_var($_SERVER['HTTP_X_REAL_IP'], FILTER_VALIDATE_IPFILTER_FLAG_IPV6) !== FALSE
              
      || filter_var($_SERVER['HTTP_X_REAL_IP'], FILTER_VALIDATE_IPFILTER_FLAG_IPV4) !== FALSE))
        
      $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
      if (!empty(
      $_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
        
      $_SERVER['HTTPS'] = 'on';
        
      $_SERVER['SERVER_PORT'] = 443;
      }
      ?>

    Répondre à ce message

  • 1

    bonjour
    est ce que ce plugin va etre adapté à spip 3.2 ?

    • Salut,

      tu peux deja tester en modifiant dans paquet.xml

              compatibilite="[2.1.11;3.1.*]"

      par

              compatibilite="[2.1.11;3.2.*]"

      cela te permettrait d’actover le plugin. Si le plugin fonctionne bien, signale le nous.

    Répondre à ce message

  • Jaseur Boreal

    Bonjour,

    Depuis juillet 2016, TOUS les sites hébergés sur un serveur mutualisé chez OVH ont un certificat SSL (gratuit) activé sur l’hébergement (source).

    Cela signifie qu’il est probable qu’un site chez OVH soit maintenant accessible en HTTPS, même si on n’a rien prévu pour ça.

    Google cherchant à indexer et positionner en priorité la version HTTPS d’une page si elle est disponible, le site pourra être consulté en HTTPS même si on ne l’a pas demandé.

    2 solutions :

    • Soit garder son site en HTTP, pour quelques temps.
      Dans ce cas il est conseillé de désactiver SSL dans les paramètres de l’hébergement OVH, et de mettre en place les redirections HTTPS vers HTTP concernées.
    • Soit migrer complètement vers HTTPS

    Et dans cette situation, le plugin Redirection HTTPS ne redirige que quelques pages si j’ai bien tout compris : « passer automatiquement en HTTPS pour les pages contenant des informations privées (espace privé, login, crayons...) »

    Comment procéder pour passer tout un site Spip 3.1 en https sans erreurs ?

    Quelles sont les précautions à prendre ?

    Merci de vos conseils

    Répondre à ce message

  • Plugin indispensable ! et bravo
    Cependant et sauf erreur, une fois que l’on s’est connecté tout le site (même les parties en accès public) reste en https et idem après déconnection.
    Dans mon cas c’est génant sur un point précis : j’ai un code de redirection dans une page publique.
    Comment faire pour annuler https juste sur cette page ou cette redirection ?

    Merci par avance

    Répondre à ce message

  • 1
    Laëtitia

    Bonjour, j’ ai grand besoin de vos lumières,

    je n’arrive pas à comprendre... le plugin agit seulement sur les pages sensibles du site, mais les autres restent alors en HTTP ?
    Faut il intervenir dans le .htaccess afin que tout le site soit en HTTPS, ou bien avec ce plugin les HTTP et HTTPS cohabitent ?

    Merci d’avance

    • laetitia

      Ma question est si bête que ça ? ;-)

    Répondre à ce message

  • Merci pour ce plugin, il répond à un besoin que j’avais.
    Toutefois il réagit très mal avec les sous-domaines apparemment. Je ne sais pas où regarder dans le code source du plugin mais il semble qu’il redirige vers la racine du serveur lorsqu’il est activé et lorsqu’il passe en mode https. Il devient pour ma part inutilisable avec un spip en sous domaine et/ou un spip installé dans un sous-répertoire de l’hébergement.

    Je précise que dans mon cas il y avait deux spip en 3.0.17 :
    -  Un en sous-domaine et en sous-répertoire qui possédait le plugin activé.
    -  Un en répertoire proncipal (à la racine) et en nom de domaine principal sans le plugin activé ni installé.
    Résultat : lorsque je me connectais sur le backoffice spip du sous-domaine, je basculais en fait vers le spip du domaine principal (alors que dans la barre d’adresse j’avais toujours l’url du sous domaine).

    J’espère que ce petit bug pourra être reproduit et corrigé de votre côté...

    Répondre à ce message

  • 1

    Bonjour,

    un petite question un peu hors sujet.
    Sur un site avec spip 3.0.17. Le theme du site avec son css et webfonts se trouvent dans un plugin.

    En http le tout fonctionne bien. Si je bascule en https le webfont provoquent des erreurs « mixed content » et les web-fonts sont bloqués.

    Si j’active le présent plugin cela marche seulement quand je suis connecté mais pas quand je me déconnecte.

    Si je regarde le code de ce plugin je voie qu’il utilise la redirection de spip : redirige_par_entete('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);"

    est-ce la seule manière d’éviter de problème de « mixed content » si on utilise https avec spip ?

    car avec

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}"

    les erreurs « mixed content » persistent ?

    Cordialement
    Rainer

    • Bonjour,
      Je ne sais pas si cela t’aidera mais ne serait-il pas mieux de mettre le chemin du webfont vers sa version https?
      Concrètement dans ton css au lieu d’avoir par exemple :

      Tu peux modifier en :

      Comme cela ton navigateur n’aura pas deux contenus (http et https)...
      Il faut pour cela modifier la css qui gère cette webfont.

    Répondre à ce message

  • 1

    Bonjour,

    Je ne pense pas que vous ayez prévu le cas des identifications tout en restant sur le site public comme avec #LOGIN_PUBLIC par exemple ou les formulaires maisons.

    ça envoie un POST sur / (POST / HTTP/1.1)
    Content-Type : application/x-www-form-urlencoded

    formulaire_action=login&formulaire_action_args=XXX&var_login=redacteur&nothing=&password=XXX

    La difficulté c’est le formulaire se charge généralement avec la première page du site qu’on ne peut pas passer en https (sinon autant passer tout le site en https)

    Une idée ?

    • Effectivement, je n’avais pas prévu ça. On peut penser à plusieurs solutions :

      • toute la page en https
      • seulement mettre un lien vers la page de login
      • charger #LOGIN_PUBLIC par ajax, et en https.

    Répondre à ce message

  • 1

    Bonjour,
    ce plugin permet-il de rediriger en https les accès aux éléments restreints par le plugin « accès restreint » ?
    merci,
    Sylvain

    Répondre à ce message

  • 1

    Bonjour,
    Je viens de l’activer et je n’ai plus accès à la page de login. J ’ai l’erreur :
    Erreur de connexion SSL
    Impossible d’établir une connexion sécurisée avec le serveur. Le serveur a peut-être rencontré un problème ou exige un certificat d’authentification du client dont vous ne disposez pas.
    Erreur 107 (net::ERR_SSL_PROTOCOL_ERROR) : Erreur de protocole SSL

    Comment le desactiver sans l’acces à l’espace privé ?
    Merci

    • Ah oui c’est embêtant.

      Le plus simple c’est de commenter le contenu du fichier redirhttps_options.php du plugin. Ou encore plus simple, renommer le fichier pour qu’il ne soit plus pris en compte.

    Répondre à ce message

Ajouter un commentaire

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom

Dernière modification de cette page le 23 décembre 2017