|
|
||
| Date de création : | 15 décembre 2003 | |
| Dernière modification : | 10 avril 2004 | |
| Diffusion : | internet | |
Le projet esup-portail a besoin de mettre en oeuvre rapidement un serveur webdav qui réponde aux fonctionnalités attendues pour la version 1 (voir le document sur l'espace de stockage - PDF - PPT).
Pour rappel, le besoin pour la version 1 est d'offrir un espace de stockage privé aux utilisateurs, avec des fonctionalités réduites (pas de partages, ...) ; il suppose un accès depuis une application de confiance (trusted), qui se contente de présenter l'identifiant de la personne, et éventuellement un mot de passe partagé.
Le projet d'espace de stockage définitif est ambicieux, et suppose des développements lourds.
Aussi, nous avons pris l'option d'utiliser pour la version 1 un serveur pour lequel il n'y aura quasiment pas de développement ; ce serveur sera remplacé rapidement par un serveur plus performant au niveau fonctionnalités et scalabilité.
Le choix s'est porté sur le serveur apache V2, avec le module mod_dav et des modules dérivés de modules apache existants.
Le package de ces modules et des utilitaires associés et disponible dans l'espace de download.
Un document dédié à l'installation et au paramétrage des modules et utilitaires est disponible ici.
Les spécifications du serveur V1 nécessitent l'adaptation de modules existants ; cette adaptation est très légère.
C'est un module d'autorisations. Son but est d'autoriser toute requête authentifiée, sans mot de passe, ou avec un mot de passe partagé pour tous (un 'secret' entre l'application de gestion de stockage et le serveur DAV).
Ce module est dérivé des modules mod_auth_anon et mod_auth
Il accepte les directives suivantes, à mettre dans un <Directory>, un <Location>, un .htaccess (les directives sont dérivées de mod_auth_anon) :
déclare un espace protégé par ce module. Cette directive peut être suivie sur la même ligne d'un ou plusieurs mots : ce sont des logins qui ne sont pas autorisés par le module. (fonctionnement inverse de auth_anon ; intérêt limité, voire nul ;-).
si Off, on autorise un mot de passe vide.
Peut contenir un mot : c'est
un mot de passe imposé (secret partagé avec le
client).
Si présent, suppose que Esup_MustGivePassword
est à On
Si On, on ne peut authentifier qu'en mode Esup. Sinon, on peut chainer d'autres modules d'authentif.
A tester plus avant. A priori, l'option Off ne semble pas judicieux dans le projet.
Il est possible de protéger les ressources d'une manière classique, par des 'require user', ou un 'require valid-user' sur la resource.
Ce module est chargé de faire un mappage des URLs personnels avec un espace 'file système'. Il suppose qu'une URL personnelle commence par le caractère '~'.
Il ne peut pas être chargé en même temps que mod_userdir.
Par exemple, si l'url du serveur est http://docweb.univ.fr , et que la racine des 'home directories' utilisateurs est sur /home/www/users
On désire que http://docweb.univ.fr/~unuser pointe vers l'espace file-système : /home/www/users/u/un/unuser, donc faire un 'hachage' du nom, ceci pour optimisations diverses.
Nous avons modifié le module mod_userdir à cet usage.
ATTENTION
: les modules mod_userdir-esup et mod_userdir ne peuvent pas
être chargés simultanément.
Il accepte les mêmes directives qu'auparavant (voir la doc apache V2), plus
la directive optionnelle 'with_hash'
Si pas présent ni with_hash_reverse, le module userdir fonctionne comme auparavant.
Si présent, l'algo de haschage est appliqué.
Par exemple :
UserDir /home/www/users
UserDir with_hash
Réalise la
transformation recherchée
précédemment, c'est à dire le mapping
de ~unuser
vers /home/www/users/u/un/unuser
(sans l'option with_hash, le mapping aurait été
fait vers /home/www/users/unuser).
Même chose que
précédemment, pour un algo de hashage inverse :
~unuser
vers ../r/re/unuser
donc en partant de la fin du nom de l'utilisateur.
Nous avons rencontré des dysfonctionnements lors d'accès de type "webFolders" avec Windows XP :
Lors de l'accès avec le nom d'utilisateur unuser sur l'URL http://docweb.univ.fr/~unuser, Windows tente d'authentifier l'utilisateur docweb.univ.fr\unuser (au lieu de unuser), ce qui n'est bien sûr pas reconnu.
Ce problème n'est pas lié aux modules patchés esup : il se reproduit en authentification LDAP, sans module 'esup', par exemple avec la directive :
Alias /~unuser "/home/www/users/u/un/unuser"
Des problèmes identiques sont répertoriés sur Internet ; nous n'avons pas su le corriger proprement.
Ce qui est étrange, et testé tardivement, par hasard : ca marche en https!!
Ainsi, avec une config du genre :
<VirtualHost xxx.xxx.xxx.xxx:80>
ServerName docweb.univ.fr
include conf/storage_untrusted.conf
</VirtualHost>
<VirtualHost xxx.xxx.xxx.xxx:443>
ServerName docweb.univ.fr
#untrustedSSL.conf contient les directives SSL dpecifiques a docweb
include conf/storage_untrustedSSL.conf
include conf/storage_untrusted.conf
</VirtualHost>
Ca marche en https, et pas en
http!!
A noter que c'est cette config qui est proposée en exemple.
Le fichier
storage_untrustedSSL.conf ne contient que les directives suivantes :
SSLEngine on
SSLCipherSuite ...
SSLCertificateFile
SSLCertificateKeyFile
SSLCACertificateFile
SSLVerifyClient none
Ce qui est décrit ici n'est pas un dysfonctionnement, mais un fonctionnement gênant en accès DAV :
Par config apache, nous avons interdit tout accès aux fichiers .ht*.
Ceci n'empêche pas l'utilisateur de voir ce fichier lors d'un accès Dav : le listage est obtenu grâce à la directive Dav PROPFIND, qui n'est pas concerné par cette restriction d'accès.
Ce comportement est perturbant ; il pourrait être corrigé à l'aide d'un patch certainement mineur du module mod_dav (éliminer la visibilité des fichiers .ht* lors de requêtes PROPFIND).
| Création : 15 décembre 2003 - Vincent Mathieu | |
|
Modifications : |