Forcer la connexion via HTTPS

Voir https://www.dokuwiki.org/plugin:forcessllogin, ne semble pas refléter l'accès SSL dans l'URL, c'est-à-dire que la page d'accès refusé de dokuwiki ne sera pas ouverte via le protocole https, ce qui facilite le débogage et garantit que vous vous connectez en toute sécurité en difficile.

En utilisant le mod_rewrite d'Apache, les connexions DokuWiki peuvent être forcées d'utiliser HTTPS, empêchant ainsi les mots de passe en texte clair sur le réseau.

Vous devrez peut-être également que toutes les requêtes (et pas seulement la connexion) utilisent HTTPS. Pour cela, créez un fichier .htaccess dans le répertoire racine de DokuWiki et insérez le code suivant.

.htaccess

RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]

Si vous souhaitez uniquement forcer une URL spécifique, lisez d'abord URL rewriting.

La redirection vers une connexion sécurisée restreinte à un certain ensemble de pages (par exemple les pages de connexion) nécessite leur reconnaissance sur la base de l'URL. Certaines pages (par exemple, les pages “accès refusé” qui peuvent être incluses uniquement dans les versions plus récentes, par exemple 2014-05-05 “Ponder Stibbons” <ref>https://www.dokuwiki.org/plugin:ondeniedlogin</ref>) don 'inclut pas une telle marque et ne peut pas être distingué du reste des URL (auxquelles on peut vouloir accéder sans connexion sécurisée afin d'économiser les ressources du serveur).

Le reste du paragraphe ne gère que les requêtes avec une requête GET ?do=login qui ne couvre pas au moins les pages “accès refusé” ! La recherche d'une règle de redirection pour toutes les requêtes d'authentification sur HTTP est nécessaire.
Voir la discussion pour la solution.

Ce qui suit suppose que vous avez déjà configuré le support HTTPS pour votre wiki, le rendant disponible via HTTP et HTTPS sur la même adresse. Pour des raisons de performances, seules les mises à jour de connexion et de profil doivent être forcées en HTTPS tandis que toutes les actions “normales” du wiki continueront à fonctionner sur HTTP.

Étant donné que vous devez configurer des cookies via HTTPS pour fonctionner également sur HTTP, vous devez d'abord désactiver l'option securecookie. Procédez ensuite à la mise en place de la redirection dans votre .htaccess :

# Switch to secure on login, profile and admin actions
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteCond %{QUERY_STRING} do=(log|profile|admin)
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,QSA,L,NE]

# Change back to non-secure on show action
RewriteCond %{HTTPS} on
RewriteCond %{QUERY_STRING} !do=(log|profile|admin)
RewriteCond %{REQUEST_METHOD} GET
RewriteRule ^(.*) http://%{HTTP_HOST}/$1 [R,QSA,L]

Vous pouvez remplacer ${HTTP_HOST} par ${SERVER_NAME}, où le nom du serveur correspond au nom d'hôte dans votre certificat SSL.

Remarques:

• ce qui précède revient à non-SSL sur l'action d'affichage uniquement. Cela signifie que le retour en arrière peut ne pas se produire immédiatement après la connexion, mais garantit qu'il n'y aura pas d'avertissements de “contenu mixte” pendant l'opération SSL.

• si vous avez d'autres règles de réécriture, telles que celles utilisées dans la réécriture générale, placez ces règles avant les autres.

• si le répertoire d'installation de votre DokuWiki n'est pas le répertoire racine (quelque chose comme http://example.com/wiki/), vous devez ajouter ce chemin supplémentaire aux lignes 5 et 11 du ci-dessus, qui sera donc quelque chose comme : RewriteRule ^(.*) http://%{HTTP_HOST}/wiki/$1 [R,QSA,L]

Veuillez noter : Vous devez désactiver le “securecookie” dans conf/dokuwiki.php pour que le code ci-dessus fonctionne. Sinon, vos identifiants ne seront pas enregistrés avec succès. En effet, avec securecookie activé, le cookie de session créé lors de la connexion HTTPS ne peut pas être envoyé via HTTP et la session est perdue.

Cette configuration est également possible dans nginx mais avec une modification mineure de vos fastcgi_params.

Tout d'abord, vous devez avoir des instances de serveur distinctes, pour http et https chacune, pour garder les choses propres (et pour rewrite pour ne pas être confus et être piégé dans des boucles redir). Cela peut ressembler à ceci. Chaque instance a sa propre règle de réécriture pour passer de http à https.

# Tested with nginx 0.8.5
# In http context of your nginx configuration
map $scheme $php_https { default off; https on; }

    server {
	server_name wiki.host.org
	root /path/to/dokuwiki;
	index doku.php;
	listen 80;
	#Enforce https for logins, admin
	if ($args ~* do=(log|admin|profile)) {
		rewrite ^ https://$host$request_uri? redirect;
	}
	include dokuwiki.conf;
    }

    server {
	server_name wiki.host.org;
	root /path/to/dokuwiki;
	index doku.php;
	listen 443 ssl;
	keepalive_requests    10;
	keepalive_timeout     60 60;
	ssl_certificate      /etc/ssl/certs/ssl-cert-snakeoil.pem;
	ssl_certificate_key  /etc/ssl/private/ssl-cert-snakeoil.key;
	#switch back to plain http for normal view

	if ($args ~* (do=show|^$)){
		rewrite ^ http://$host$request_uri? redirect;
	}
	include dokuwiki.conf;
    }

Dans dokuwiki.conf (même chemin que votre nginx.conf), vous pouvez utiliser le extrait du wiki nginx, mais vous devez ajouter

fastcgi_param HTTPS $php_https;

à vos fastcgi_params. Ce paramètre et la directive map au début sont requis car Dokuwiki vérifie que $_SERVER['HTTPS'] fonctionne.

Comme avec apache, vous devez désactiver securecookie dans votre conf/dokuwiki.php.

Ci-dessous est utile si vous souhaitez TOUJOURS forcer la connexion https (pas seulement pour la connexion) et ne souhaitez pas vous fier à Apache ou NGINX htaccess ou à d'autres directives spécifiques au serveur. Placez les lignes ci-dessous au-dessus du fichier de modèle à '…lib/tpl/template-name/main.php'

<?php
if ($_SERVER[HTTPS]!="on") {
  //$strURIName=$_SERVER['SERVER_NAME'] . getenv("REQUEST_URI"); 
  // The function 'getenv' does not work if your Server API is ASAPI (IIS).
  // So, try to don't use getenv('REMOTE_ADDR'), but $_SERVER["REMOTE_ADDR"].
  $strURIName= $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];
  header ("Location: https://$strURIName");
  // If it doesn't work for you and you need to troubleshoot your php code, 
  // uncomment below to find out about your particular server variables
  /*
  echo "<b>_SERVER Variables from $_SERVER</b><br><br>";
  reset($_SERVER);
  while (list ($key, $val) = each ($_SERVER)) {
  print $key . " = " . $val . "<br>";
  }
  */
}
 
?>

La réécriture d'URL n'est-elle pas nécessaire pour que la réécriture pour la connexion fonctionne afin que la phrase soit plus claire ? Moi-même je n'en suis pas arrivé là jusqu'à présent, mais en ce qui me concerne, la gestion de certains paramètres de configuration comme basedir, et la définition de la valeur $conf['userewrite'] appropriée (voir aussi Discussion) semble crucial — krichter 2014-06-02 01:11

Ces instructions sont-elles à jour pour 2014-05-05 “Ponder Stibbons” ? Si oui, existe-t-il un modèle pour inclure un aperçu des versions testées (avec indication si cela fonctionne pour eux ou non, comme pour les plugins) - facilite énormément la recherche. Si non, y a-t-il quelqu'un qui a une idée (avec la redirection vers HTTPS (première section pour .htaccess je le fais fonctionner partiellement - c'est plus aléatoire en fait - et avec les deux sections je reçois un avertissement de redirection sans fin de firefox (essayé environ 20 à 30 combinaisons avec des indices de general rewriting et j'ai abandonné…

J'ai créé la solution aux pages “accès refusé” qui permet de réécrire les règles pour rediriger l'utilisateur vers une page de connexion SSL. Ce correctif était une modification du code source qui redirige l'utilisateur vers la même page avec la chaîne de requête 'do=login', cela permet aux règles de réécriture de prendre effet et de rediriger vers une page de connexion SSL, une fois que l'utilisateur se connecte, ils seront présentés avec la page à laquelle ils ont essayé d'accéder. Ce correctif se trouve sur mes sites Web ‘bug and feature tracker’ sous forme de fichier correctif. Jon, No Fuss Computing.

J'essaie de CASsifier mon Dokuwiki avec phpCAS. Mon serveur CAS n'autorise pas les services http (que je pourrais changer mais ce n'est pas mon but).
J'ai donc installé le plugin authplaincas avec succès et la bibliothèque phpCAS aussi. Tout est OK sauf une chose : Client.php de la lib phpCAS ne renvoie pas le service au serveur CAS avec https mais uniquement avec http. J'ai pu faire une astuce que je poste ici : https://github.com/Jasig/phpCAS/issues/178
J'ai d'abord pensé que phpCAS était le problème, puis c'était Dokuwiki et encore phpCAS mais maintenant je pense que c'est DokuWiki qui signale le mauvais service de protocole. J'ai essayé différentes solutions comme le moteur de réécriture dans .htaccess mais cela conduit à une boucle infinie (j'ai désactivé l'option de cookie sécurisé). Pour plus d'informations, j'utilise un proxy inverse Apache2.4 avec redirection permanente 80 vers 443 et un backend web avec Apache2.4 avec HTTP uniquement. Je pense que le problème est que les informations du protocole HTTPS ne sont pas transmises à mon backend qui héberge mon DokuWiki ou lorsque j'obtiens une boucle infinie, je pense que mon cookie n'est pas conservé. Comment puis-je le réparer ou le déboguer? L'aide sera très appréciée.

Salutations,
Guy CARRÉ
guycarre au point gratuit fr

ÉDITER J'ai trouvé ce qui n'allait pas et je le poste ici : https://github.com/Jasig/phpCAS/issues/178

Bonsoir

Sur HTTP, non connecté sur une page inexistante si vous essayez d'afficher la source (do=edit), vous “do=login” implicitement, sur HTTP. Je suggère de passer en https sur “do=(login|admin|profile|edit)”.
De plus, je ne suis pas sûr que cette configuration ait vraiment besoin de désactiver le cookie sécurisé, elle en a besoin activé pour moi. En fait, voler un cookie est aussi simple que voler un mot de passe en clair. Ok, ça ne dure pas aussi longtemps, et n'est pas aussi puissant (ou est-ce que c'est le cas)..
En repassant en http, vous perdez la session : les capacités d'édition, de configuration, etc., qu'est-ce qui ne va pas avec cela ? Faire une telle action vous ramène en https, le cookie est envoyé et vous récupérez votre session. Peut-être que d'autres actions doivent passer en https, comme les médias, etc., je ne sais pas.
Ce ne sont que des suggestions, je ne maîtrise ni dokuwiki ni http(s)(serveur ou protocole).

Nous devrions modifier cette astuce pour recommander l'utilisation de TLS pour toutes les connexions. Selon le commentaire “30 novembre 15 - faire” ci-dessus, si vous envoyez le cookie de manière non sécurisée pour une session active, il peut être volé de manière triviale car le cookie traverse le fil en clair. Firesheep rend cette tâche automatisée et simple à exécuter. De plus, OWASP les meilleures pratiques consistent à exécuter tout en toute sécurité tout le temps. Enfin, nous devrions recommander au vhost 443 d'envoyer également l'en-tête HTTP Strict Transport Security (HSTS). Cela se fait avec une seule ligne dans le vhost 443 (pour Apache dans cet exemple) :

L'en-tête est toujours défini sur Strict-Transport-Security "max-age=63072000; preload"

Une étape supplémentaire serait de recommander fortement que TLS soit configuré par défaut. Bien que cela rende l'installation plus difficile techniquement, avoir une configuration par défaut pour envoyer les identifiants de connexion en clair est une mauvaise idée.