Modèle de communication réseau

À un moment ou à un autre, vous aurez besoin de comprendre comment le client Subversion communique avec le serveur. La couche réseau de Subversion est abstraite, c'est-à-dire que les clients Subversion ont le même comportement quel que soit le type de serveur auquel ils ont affaire. Qu'ils communiquent via le protocole HTTP (http://) avec un serveur HTTP Apache ou via le protocole Subversion (svn://) avec svnserve, le modèle de communication réseau est le même. Dans cette section, nous expliquons les fondamentaux de ce modèle de communication réseau, y compris la façon dont Subversion gère les authentifications et les autorisations.

Requêtes et réponses

Le client Subversion passe la plupart de son temps à gérer des copies de travail. Cependant, quand il a besoin d'informations disponibles dans un dépôt distant, il envoie une requête sur le réseau et le serveur lui répond. Les détails du protocole réseau sont cachés à l'utilisateur : le client essaie d'accéder à une URL et, suivant le format de cette URL, utilise un protocole particulier pour contacter le serveur (voir URL du dépôt).

[Astuce] Astuce

Tapez svn --version pour voir quels types d'URL et de protocoles sont utilisables par votre client.

Quand le serveur reçoit une requête d'un client, il demande souvent au client de s'identifier. Il envoie un défi d'authentification vers le client et le client répond en fournissant les éléments d'authentification au serveur. Une fois cette authentification terminée, le serveur répond à la requête originale du client. Remarquez que ce fonctionnement est différent de celui de CVS où le client envoie systématiquement au préalable ses identifiants de connexion (procédure de « log in »), avant même de formuler la moindre requête. Dans Subversion, le serveur requiert explicitement l'authentification du client (par un défi d'authentification) au moment approprié, au lieu que ce soit le client qui s'authentifie a priori. Certaines opérations sont donc effectuées plus élégamment. Par exemple, si un serveur est configuré pour laisser tout le monde accéder au dépôt en lecture, alors le serveur n'envoie jamais de défi d'authentification quand un client tente un svn checkout.

Si une requête d'un client conduit à la création d'une nouvelle révision du dépôt (par exemple un svn commit), alors Subversion utilise le nom d'utilisateur fourni lors de la phase d'authentification comme auteur de la révision. C'est-à-dire que le nom d'utilisateur est stocké dans la propriété svn:author de la nouvelle révision (voir la section intitulée « Propriétés dans Subversion »). Si le client n'a pas été authentifié (en d'autres termes, si le serveur n'a jamais envoyé de défi d'authentification), alors la propriété svn:author de la révision est vide.

Mise en cache des éléments d'authentification du client

Beaucoup de serveurs sont configurés pour demander une authentification à chaque requête. Ce serait particulièrement pénible pour les utilisateurs s'ils devaient taper leur mot de passe à chaque fois. Heureusement, le client Subversion a une solution : la mise en cache sur le disque des éléments d'authentification. Par défaut, si le client en ligne de commande s'authentifie avec succès auprès d'un serveur, le client sauvegarde les éléments d'authentification dans une zone privée propre à l'utilisateur (~/.subversion/auth/ sur les systèmes de type Unix ou %APPDATA%/Subversion/auth/ sur Windows) ; voir la section intitulée « Zone de configuration des exécutables » pour plus de détails). Les éléments d'authentification sont mis en cache sur le disque, classés suivant une combinaison du nom, du port et du domaine d'authentification du serveur.

Quand le client reçoit un défi d'authentification, il regarde d'abord s'il dispose des éléments appropriés dans le cache disque de l'utilisateur. Si ce n'est pas le cas, ou si les éléments conduisent à un échec lors de la tentative d'authentification, le client demande alors (c'est son comportement par défaut) à l'utilisateur les informations nécessaires.

Ici, le lecteur soucieux de sécurité va immédiatement commencer à s'inquiéter : « Mettre en cache des mots de passe sur le disque ? Quelle horreur ! Jamais ! »

Les développeurs de Subversion reconnaissent le bien fondé du problème et c'est pourquoi Subversion est capable de fonctionner avec les différents mécanismes offerts par le système d'exploitation et l'environnement de travail pour minimiser les risques de fuites d'information. Voici ce que cela veut dire sur les plateformes les plus courantes :

  • Sur Windows 2000 et ses successeurs, le client Subversion utilise les services cryptographiques standards de Windows pour chiffrer le mot de passe sur le disque. Comme la clé de chiffrement est gérée par Windows et qu'elle est associée à l'identifiant de connexion de l'utilisateur, lui seul peut déchiffrer le mot de passe en cache. Notez que si le mot de passe de l'utilisateur est réinitialisé par un administrateur, tous les mots de passe en cache deviennent indéchiffrables. Le client Subversion agit comme s'ils n'existaient pas, en redemandant le mot de passe quand c'est nécessaire.

  • De manière similaire, sur Mac OS X, le client Subversion stocke tous les mots de passe dans le jeton de connexion (géré par le service « Keychain »), qui est protégé par le mot de passe du compte utilisateur. La configuration des « préférences utilisateur » peut imposer une politique plus stricte, comme par exemple demander le mot de passe du compte utilisateur à chaque fois qu'un mot de passe Subversion est utilisé.

  • Pour les systèmes de type Unix, il n'existe pas de standard de service de type « Keychain ». Cependant, la zone de cache auth/ est toujours protégée par les droits système et seul l'utilisateur (le propriétaire) des données peut les lire. Les droits sur les fichiers fournis par le système d'exploitation protègent les mots de passe.

Bien sûr, si vous êtes complètement paranoïaque, aucun de ces mécanismes n'est parfait. Ainsi, pour ceux qui sont prêts à sacrifier le confort d'utilisation au profit de la sécurité absolue, Subversion fournit de nombreuses façons de désactiver le système de cache d'authentification.

Pour désactiver le système de cache pour une seule commande, utilisez l'option --no-auth-cache :

$ svn commit -F log_msg.txt --no-auth-cache
Domaine d'authentification : <svn://hote.exemple.com:3690> exemple de domaine
Nom d'utilisateur :  paul
Mot de passe pour 'paul' :

Ajout         nouveau_fichier
Transmission des données .
Révision 2324 propagée.

# le mot de passe n'a pas été mis dans le cache, donc la deuxième propagation
# nous redemandera le mot de passe

$ svn delete nouveau_fichier
$ svn commit -F nouveau_msg.txt
Domaine d'authentification : <svn://hote.exemple.com:3690> exemple de domaine
Nom d'utilisateur :  paul
…

Autrement, si vous voulez désactiver la mise en cache des éléments d'authentification de manière permanente, vous pouvez éditer le fichier config de votre zone de configuration et mettre l'option store-auth-creds à no. La mise en cache des éléments d'authentification est alors désactivée pour toutes les commandes Subversion que vous effectuez sur cet ordinateur. Ceci peut être étendu à l'ensemble des utilisateurs de l'ordinateur en modifiant la configuration globale de Subversion (voir la section intitulée « Agencement de la zone de configuration »).

[auth]
store-auth-creds = no

Il arrive que les utilisateurs veuillent effacer certains mots de passe du cache disque. Pour ce faire, vous devez vous rendre dans la zone auth/ et effacer manuellement le fichier de cache approprié. Les éléments d'authentification sont mis en cache dans des fichiers individuels ; si vous affichez chaque fichier, vous voyez des clés et des valeurs. La clé svn:realmstring décrit le domaine du serveur auquel est associé le fichier :

$ ls ~/.subversion/auth/svn.simple/
5671adf2865e267db74f09ba6f872c28
3893ed123b39500bca8a0b382839198e
5c3c22968347b390f349ff340196ed39

$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28

K 8
username
V 3
paul
K 8
password
V 4
blah
K 15
svn:realmstring
V 45
<https://svn.domaine.com:443> Dépôt de Paul
END

Une fois le bon fichier trouvé, effacez-le.

Un dernier mot sur la façon dont svn gère l'authentification, avec un zoom sur les options --username et --password. Beaucoup de sous-commandes du client acceptent ces options, mais il est important de comprendre que l'utilisation de ces options n'envoie pas automatiquement les éléments d'authentification au serveur. Comme vu précédemment, le serveur demande explicitement l'authentification au client quand il estime que c'est nécessaire ; le client ne les envoie pas à sa convenance. Même si un nom d'utilisateur et/ou un mot de passe sont passés en option, ils ne sont envoyés au serveur que si celui-ci les demande. Ces options sont couramment utilisées pour s'authentifier sous un nom d'utilisateur différent de celui que Subversion aurait choisi par défaut (comme votre nom de compte système), ou quand on ne veut pas de commande interactive (par exemple, utilisation de la commande svn dans un script).

[Note] Note

Une erreur classique consiste à mal configurer un serveur de telle sorte qu'il n'envoie jamais de défi d'authentification. Quand les utilisateurs passent les options --username et --password, ils sont surpris de voir qu'elles ne sont jamais utilisées, c'est-à-dire que les nouvelles révisions semblent toujours avoir été propagées de façon anonyme !

En résumé, voici comment un client Subversion se comporte quand il reçoit un défi d'authentification :

  1. D'abord, le client vérifie si l'utilisateur a spécifié explicitement des éléments d'authentification dans la ligne de commande (options --username et/ou --password). Si c'est le cas, le client essaie de s'authentifier auprès du serveur avec ces éléménts.

  2. Si les éléments d'authentification ne sont pas passés en ligne de commande, ou si ceux qui ont été fournis ne sont pas valides, le client regarde dans la zone auth/ s'il trouve le nom, le port et le domaine du serveur pour voir si l'utilisateur a déjà les éléments d'authentification en cache. Si c'est le cas, il essaie d'utiliser ces éléments pour s'authentifier.

  3. Finalement, si les mécanismes précédents ont abouti à des échecs d'authentification sur le serveur, le client se résout à demander les éléments à l'utilisateur (à moins qu'il ne lui ait été indiqué de ne pas le faire via l'option --non-interactive ou son équivalent spécifique au client).

Si le client réussit à s'authentifier par l'une ou l'autre de ces méthodes, il essaie de mettre en cache les éléments d'authentification sur le disque (à moins que cette fonctionnalité ne soit désactivée, comme indiqué auparavant).