====== Forcer la connexion via HTTPS ======
===== Plugins ======
==== force la connexion ====
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.
=====Apache=====
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.
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]
Si vous souhaitez uniquement forcer une URL spécifique, lisez d'abord [[:rewrite|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" [https://www.dokuwiki.org/plugin:ondeniedlogin]) 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).
FIXME 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 [[fr:config: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 [[fr:rewrite|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]''
====cookie sécurisé====
**Veuillez noter :** Vous devez désactiver le "[[fr:config: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.
=====nginx=====
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 [[http://wiki.nginx.org/Dokuwiki|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|securecookie]] dans votre ''conf/dokuwiki.php''.
===== HTTPS basé sur 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'''
_SERVER Variables from $_SERVER
";
reset($_SERVER);
while (list ($key, $val) = each ($_SERVER)) {
print $key . " = " . $val . "
";
}
*/
}
?>
===== Discussion =====
==== La réécriture d'URL est_elle obligatoire? ====
[[fr:rewrite|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 [[ fr:rewrite#Discussion]]) semble crucial --- [[user>krichter|krichter]] //2014-06-02 01:11//
==== Mise à jour pour 2014-05-05 "Ponder Stibbons" ====
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 [[fr:rewrite|general rewriting]] et j'ai abandonné...
==== 17 juillet 14 - Correction de la connexion SSL refusée à l'accès ====
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 [[http://nofusscomputing.com/mantis/view.php?id=99 |‘bug and feature tracker’]] sous forme de fichier correctif. Jon, [[http://nofusscomputing.com|No Fuss Computing.]]
==== 25 novembre 15 - mauvais service de protocole ou boucle infinie ====
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 ;-)
==== 30 nov. 15 - faire ====
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).
==== 16 février 2016 - Utilisez TLS tout le temps ====
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. [[https://en.wikipedia.org/wiki/Firesheep|Firesheep]] rend cette tâche automatisée et simple à exécuter. De plus, [[https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Transport_Layer_Security|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 [[https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security|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.